Re: [w3c/ServiceWorker] event.waitUntil/respondWith vs return promise (#1148)

(Sorry for the delayed response)

> Yep, and it could know which events it terminated early, which wouldn't be the case if sleep(Infinity) wasn't passed.

Are you saying the browser can't know the list of outstanding tasks it terminated early without the waitUntil assist? I imagine the browser should have that knowledge à la `_getActiveHandles()`.

> It's pretty common to not waitUntil in a fetch event.

For completeness: "a developer will never not want to waitUntil _if they have scheduled something asynchronously_". That's always a bug. They might want to respond early, but not skip waiting.

> ```
> addEventListener('install', event => {
>   event.waitUntil(doAsyncStuff());
> });
>   ```

```js
addEventListener('install', event => {
  return doAsyncStuff();
});
```

Similarly, does not install if promise rejects.

> ```
> addEventListener('fetch', event => {
>   event.respondWith(
>     fetch(whatever).then(response => {
>       event.waitUntil(addThisToTheCache(response));
>       return response;
>     })
>   );
> });
> ```

```js
addEventListener('fetch', async ({ respond }) => {
  const response = await fetch(whatever)
  respond(response)
  addThisToTheCache(response)
})
```

Similarly, the user can respond early and then cache stuff later.

-- 
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/1148#issuecomment-321898638

Received on Friday, 11 August 2017 19:26:46 UTC