search

GoogleChrome / samples

A repo containing samples tied to new functionality in each release of Google Chrome.
https://www.chromestatus.com/samples
Apache License 2.0
5.79k stars 2.38k forks source link

Add ability to cache samples #376

Open beaufortfrancois opened 8 years ago

beaufortfrancois commented 8 years ago

Hey @jeffposnick,

What do you think of adding the ability for each sample to be properly cached offline? For the Web Bluetooth samples for instance, it would make a lot of sense.

I like the simple strategy stale-while-revalidate (https://paul.kinlan.me/my-blogs-service-worker-and-caching-strategy/). Any thoughts?

addyosmani commented 8 years ago

@beaufortfrancois What's the use-case you had in mind for (non-SW) samples supporting full offline caching? Outside of PWAs, I can see value in codelab samples/walkthroughs working offline but naively assume folks looking at samples from this repo just use it for reference / don't run on device that much.

beaufortfrancois commented 8 years ago

Web Bluetooth samples are maybe an exception as we use them a lot to test out BLE devices and offline can come handy. Check out our collection at https://googlechrome.github.io/samples/web-bluetooth/.

jeffposnick commented 8 years ago

I'm not a huge fan of stale-while-revalidate for this sort of templated site.

There is some cache duplication due to partial resources that would all be repeated in the composed HTML page, though those are admittedly very small and wouldn't waste a meaningful amount of storage. More of an issue is that the stale-while-revalidation would apply to each individual page instead of applying once to the shared partial templates. So if a user visits page A, then B, then we update the partial template, the next time they visit A they'll still see the old partial template, and then the next time they visit B they'll still see the old partial template, since the revalidation only applied to the composed HTML in page A.

I am in favor of putting together a service worker for the site that cached our full and partial templates, and did the composition inside the service worker. A quick search turned up a couple of JavaScript implementations of the Liquid templating language that gh-pages uses via the Jekyll build process:

(They seem to render to strings rather than progressively to a ReadableStream, but that's not a hard requirement.)

My objections to stale-while-revalidate aren't very strenuous. It's mainly that service workers for this sort of templated site is very much on everyone's mind right now, and I'd vote for doing what we'd end up recommending as a best-practice if we're going to do anything at all.

beaufortfrancois commented 8 years ago

As you've noted, the stale-while-revalidate pattern was just a first step to get a nice service-worker for our Chrome samples.The only thing I would be afraid of with a service worker doing the composition is that it would differ with the actual generated html file from Jekyll.

jeffposnick commented 8 years ago

Yup, I have no idea whether those libraries offer full fidelity with what you'd get running Jekyll.

But we have a chance to iron out the kinks and find a viable solution that others can then reuse!

This is a longer-term project and if you think that the lack of offline support is really hurting users of the Bluetooth API samples, then I'm not going to prevent you from rolling out a targeted service worker that is scoped to that sub-path.

beaufortfrancois commented 8 years ago

Yeah, I'd like to start with this simple and not scalable approach first for a subset of our samples and think about a love story between service worker & Jekyll.

Should we even name the Jekyll Service Worker edward-hyde.js?

beaufortfrancois commented 8 years ago

As discussed offline, I've merged Web Bluetooth PR and we'll figure out how to scale for all chrome samples.