Re: [ServiceWorker] Allow respondWith() to be called asynchronously or allow some way to cancel the response. (#836)

If we let evt.respondWith() happen async so different handlers could respond over time.  How would we handle the case where none of the handlers chose to intercept?  At what point would we proceed with normal processing?

If the answer is "the waitUntil() promise", then that seems the same as passing a promise to .respondWith() and using middleware to me.  The event handlers have to coordinate to resolve the waitUntil promise together, so middleware is already in use here.

An alternative that might be implementable would be something like:

1) If FetchEvent.respondWith() is not called synchronously, then normal network processing takes place like today.
2) If FetchEvent.respondWith() is called again (sync or async) with a promise, we don't throw like today, but instead override the respondWith() promise with the new promise.
3) If FetchEvent.respondWith() is called again (sync or async) with null or undefined, reset the network request to the default behavior.

So you could immediately provide a respondWith() that is not really resolved.  Then let event handlers replace it at a later time.  And then finally have the option of letting the request proceed to the network.

The event handlers would still need some coordination to deal with the "no one wants to intercept this so let the network request proceed" case.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/836#issuecomment-186470528