Service workers in create-react-app v2
Spurred on by this Twitter thread, I wanted to share some thoughts in a longer forum than Twitter would allow.
Here's my thinking:
These are all equally valid end-states, based on the tradeoffs that make sense for each developers' use case:
1) Precache HTML in a SW, and get the benefits of navigation being reliably fast.
skipWaiting: false to ensure that precached assets are updated eventually, once all the existing tabs controlled by the old SW are closed. A recipe like this one, which could ideally be added to
c-r-a, can make this a better UX.
skipWaiting: true to ensure that precached assets are updated immediately, with the understanding that this can mess up lazy-loading. (Maybe you already have fallback logic to deal with flaky lazy loading.)
2) Use a SW that doesn't precache your HTML, but potentially offers some other benefits, like runtime caching of subresources, or displays a custom "you're offline" web page.
3) Don't use a SW at all.
Ideally developers would have the flexibility to choose which state to be in. The SW integration in
c-r-a is tricky, because the configuration is (for obviously valid reasons) locked down to the points where choosing being those options is non-trivial. That makes it important to ship with the right default behavior, one that will strike a balance between providing benefits to the user with minimal negative side effects.
c-r-a v1 shipped with
1b) by default, with the only "escape hatch" to change some runtime code and avoid registering a SW. In retrospect, that wasn't a great default.
c-r-a v2 shipped with
3) by default, with developers who explicitly opt-in ending up in
1a). I think that's a saner/safer default, but it might not be the right fit for all developers.
2) is interesting, and I don't want to say that that kind of SW is inappropriate. It's just that it really requires a level of SW configuration that you can't default to in a locked-down environment like
If developers have the ability to configure Workbox without needing to
eject, I think they'll have the tools they need to choose any of those end states.
I haven't done a great job of updating the
c-r-a docs to explain all that, and that's on me to take care of. (Update: here's a PR that will hopefully help.)