Re: [w3ctag/design-reviews] Web Locks API (#217)

> I'm wondering why the callback based API that also seems to incorporate promises was chosen. 

The best places that captures the debate is at: https://github.com/inexorabletash/web-locks/issues/9 - the design started with explicit release, but evolved away in response to feedback from @domenic, @jakearchibald and others.

The callback+promises approach sounds weird in the abstract and I was skeptical, but the resulting code ends up looking surprisingly clean. Agreed that you need to remember the `await` and `async` sprinkles. But as noted in that bug thread, writing correct code with other forms is convoluted and the language doesn't help you get it right. So... a trade off that (we felt) is somewhat closer closer to a "pit of success".

It does make the API awkward when needing explicit lifetime control; you end up recreating the explicit API with explicit promise hi-jinx. (e.g. this shows up in tests quite a bit)

> Have you considered a built in timeout or do we consider AbortController to be the right way to expose the ability to do that now?

Definitely considered — it was an explicit option in initial API sketches. Having it built in allows for the lock manager to run the timer, which is an advantage if e.g. a page is janking. But AbortController appears to be a generalization, so exposing just that for now. We look forward to developer feedback once it's implemented. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/217#issuecomment-359049179