Re: [w3ctag/design-reviews] Navigation Preload for Service Worker (#166)

@triblondon 

> It seems weird to wait on a promise in activate when, presumably confirming that preload got enabled is not a dependency of anything else in activate?

It isn't essential, but it guarantees it's enabled for your first fetch event. Otherwise, if your code assumes that `fetchEvent.preloadResponse`will give you a response for, say, navigation requests, you've got a race condition.

> I'm also confused by why this is async at all, since it doesn't touch network or document, so aren't it's performance characteristics a) well known and predictable, and b) very fast?

Async is generally used where the source/destination of the information is potentially in another thread. In this case, the worker thread and underlying service worker registration are in different threads, they involve I/O, and can be accessed from multiple contexts.

Another example of this is indexeddb - the operations aren't to do with network, but everything is async.

> I thought Alex said earlier that enable can take args

It can't. He might be thinking of `setHeaderValue`.

> I would have imagined that the existence of a promise would indicate that there's something to wait for

That was my original design, but it's (I'm told) against the rules of promises. With promises, you shouldn't mix sync and async, it's one or the other, so attribute promises should never be undefined, they should resolve with undefined.

This has come up a lot though.

> Later Jake notes that using Promise.resolve wrapper around event.preloadResponse is a good way to normalise browsers that don't support preload

This isn't a problem with async functions, where `await` implicitly uses `Promise.resolve`.

> it's kind of annoying that standard web platform features that return promises are not named to indicate that

I think in general, most properties *don't* reference their type. Eg `document.body` isn't `document.bodyHTMLBodyElement`, `document.title` isn't `document.titleString` etc etc.

> the explainer post includes an example of using a static header/footer. Jake keeps using this concept in an 'article' context and I'm confused by this because I can't think of any publishing use cases in which a page header would be sufficiently static to use this technique. Do you know of anyone doing it?

Most native apps follow this pattern. A static shell is delivered without connectivity, and the middle is filled in with network data.

In terms of on-the-web using streams specifically, it's what Facebook are looking to do, but they're using it to inject JSON into a static template. FWIW I'm merging streams on my blog https://jakearchibald.com/.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/166#issuecomment-297649806