- From: Ben Kelly <notifications@github.com>
- Date: Wed, 03 Apr 2019 10:43:04 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 3 April 2019 17:43:26 UTC
> 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