- From: Ben Kelly <notifications@github.com>
- Date: Tue, 02 Apr 2019 07:58:41 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1397/479036562@github.com>
>> 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