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

@jakearchibald I've fallen for the problem of publicly posting a load of note-to-self half baked thoughts from a first pass at understanding something someone has spent a lot of time drafting, and prompting a response from the person who cares about it deeply.  I'm sorry if it seemed a bit ignorant.

We've now had the TAG discussion, and I better understand the design decisions.  They make sense.

As a curiosity, the types thing in my mind is not quite the same as labelling all types, because promises to some extent obscure a 'real' type, which could be anything.  Having said that it seems like you can await something that is not a promise and it will just pass it through, so I'm wondering why your article needs to do `Promise.resolve(event.preloadResponse)` to normalise.  Is that because in that example you're using promise syntax rather than await?  

We discussed the possibility of multiple headers, eg `navigationPreload.setHeaders({...})`, but clearly not necessary for the initial impl, as a developer could put a serialisation of something more complex into the single header if they want to.

Regarding the streaming header pattern, sending something that doesn't extend further than `</head>` or does a bit of lightweight templating in the SW probably resolves my concern over the utility of that in more complex cases.

In summary, 👍.  We know you have a choice of review bodies for your peer review needs. We thank thank you for choosing TAG for your spec review today, please come again.

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