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

> I agree. That said, both afterResponse and responded names seem to convey that this only happens in case the fetch event is responded. Your initial proposed name 'complete' seems somehow more accurate since we are talking of completion of a fetch task and completion handlers.

Other naming ideas:

* FetchEvent.handled
* FetchEvent.fulfilled
* FetchEvent.requestHandled
* FetchEvent.complete (confusing with outstanding waitUntil, etc?)

> respondWith is not called
> respondWith is called with a response, or a promise resolving to a response

If we fulfill the promise with the consumed response then they can tell if respondWith() was called or not.

I don't think we can differentiate between a direct Response being passed vs a Promise-to-Response.  I believe WebIDL automatically coerces the direct Response to a Promise-to-Response.

> respondWith is called but no response is given, thus leading to a network error

If we expose a promise attribute this can be exposed as a promise rejection.  If we did a callback function like `afterResponse()` we would need a separate error callback I think.

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

Received on Wednesday, 3 April 2019 17:43:26 UTC