Re: [w3c/ServiceWorker] provide a way to execute work after browser has consumed a response (#1397)

>> This could also support fallback cases where respondWith() is not called at all.
> @wanderview what exactly do you mean here? Is this meant to catch a user code bug where within the fetch event handler, they literally never invoke evt.respondWith?

If you want to perform some completion work but you don't call `respondWith()` at all to fallback to network.  You want to let the browser get back to the main thread as fast as possible, but then do some work.  So something like:

```javascript
addEventListener('fetch', evt => {
  evt.waitUntil(evt.responded.then(doCompletionWork));
  if (ShouldIgnore(evt.request)) {
    // doCompletionWork() is called after the fallback to network is started
    return;
  }
  evt.respondWith(fancyResponseLoader(evt.request));
});
```

Personally it feels a bit weird to add a callback-based function like `evt.afterResponse()` when most of the API in use is promise based.  For example, if we do this callback interface you can no longer use it easily with async/await like:

```javascript
evt.waitUntil(async function() {
  await doAsyncStuff();
  await doMoreAsyncStuff();
  await evt.responded;
  return doFinalStuff();
}());
```

It also seems like someone could easily make their own `afterResponse()` wrapper built on top of the promise attribute primitive if they wanted to.  I'd rather see the browser expose the primitive than a higher level wrapper that restricts its use if you want to use it for different use cases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1397#issuecomment-479036562

Received on Tuesday, 2 April 2019 14:59:03 UTC