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

The TAG just discussed this at our London F2F meeting and concluded that:

* The callback approach has some problems in its current form:
    * Forgetting to use an async callback is a serious footgun.  It will appear to work and you may not discover the bug for some time.  Throwing an error if the callback doesn't return a promise might mitigate this.
    * The term `acquire` is inappropriate to what the method actually does.  It looks more like a transaction. A rename could mitigate this.
* We also looked at the two alternative API proposals
    * The waitUntil proposal seems like a misuse of the existing definition of that method in the serviceworker context, since the return value from `requestLock` is not an event.
    * It's confusing that the waitUntil method doesn't block, meaning that the scope in which the lock is defined becomes garbage collectable before the lock releases
    * Explicit release may have a higher likelihood of accidental long lived locks and mistakes in error handling code.
* We conceived of a fourth option, using extendable events in a manner more consistent with their use in service workers:

```javascript
const lock = new WebLock('lock-name');
lock.on('acquire', e => {
  e.waitUntil(doSomethingAsync());
});
```

* We recognise that Web Locks are not the same kind of lock as keyboard locks and wake locks, but they share the name, so the API shape being different is unexpected.  We see that this feature was previously called requestFlag and maybe that or another name should be considered.

-- 
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-362651130