gatsbygram.gatsbyjs.org SW issues

[jeffposnick]

Nice work on the gatsbygram demo!

I noticed that your SW is stuck on installing when visiting the site in a Chrome 56 Incognito window, though:

Firefox's SW debugging tools are a bit unfamiliar to me, but I think from what I can tell the SW gets installed there, but doesn't actually seem to help when you navigate back to your site while offline:

Maybe I'm doing things that weren't supposed to work—what's the intended offline functionality that you expect?

[KyleAMathews]

Hey thanks for looking over things! The service worker / offline piece is something I'm going to turn attention to soon. Right now (as of alpha 11, the latest 1.0 release earlier this week), Gatsby doesn't work offline and the service worker is pre-caching too much which I'm guessing is the reason for the install failure. We're using the webpack offline-plugin which is great for a Webpack only site but since Gatsby is a hybrid build system, offline-plugin doesn't know about much of the outputs of Gatsby so can't handle it.

I've been following along with y'alls great work on sw-helpers. I'm assuming it's still too early to use those? Stick with https://github.com/GoogleChrome/sw-precache and https://github.com/GoogleChrome/sw-toolbox for now?

Right now Gatsby has the service worker generation built-in. My plan is to move this out of core into a plugin that uses the sw-* tools to set things up. Putting this into a plugin would mean it'd be easy to support multiple SW strategies e.g. for a small site, just cache everything, for larger sites, cache a few sections and on-demand, etc.

[jeffposnick]

Yup, sw-helpers isn't quite there yet. We're targeting an alpha-quality release that has feature parity with sw-precache + sw-toolbox for around March. (And then Google I/O in May is always a good motivator to get things fully shipped and ready to use...)

sw-precache (perhaps via the webpack plugin) along with using the runtimeCaching option to integrate with sw-toolbox would be your best bet for something production-ready.

[jeffposnick]

So one thing that I'd also suggest looking into, if you haven't already, would be doing offline-first via service worker rendering, as opposed to offline-first via caching full HTML pages. Gatsby is probably in a much better place to get this done than a lot of other site generation frameworks, since your templating language should be able to run within the service worker itself. (I know React can run well enough in a web worker, so I'd assume that goes for service workers as well.)

You'd still need to precache some things, but instead of precaching HTML pages, you'd precache your individual underlying React components, and then use an appropriate caching strategy for the dynamic content that populates your views.

I've got more info about the pros and cons of those two SW architectures in this blog post (and a lot more detail in this video). In the lingo of that post, it's choosing between Option 1 and Option 3.

Special bonus points if you went with service worker rendering and also supported using the Streams API for delivering the final HTML incrementally to the client page.

[KyleAMathews]

Stream rendering from a Service Worker will be 🔥 There's actually a stream renderer for React for that'd work really well for this — https://github.com/aickin/react-dom-stream

I think initially to get something out I'll do some combo of caching HTML files / AppShell architecture but rendering from a SW is something I'd love to explore in the future.

[KyleAMathews]

@jeffposnick PR to add support for sw-precache — would love your feedback!

#687

[KyleAMathews]

With #687 merged and offline supported added, I'll close this.