Better explanation of how importScripts can extend default behavior

[jeffposnick]

One of the takeaways from @gauntface's feedback at #43 is that it's not clear how an experienced SW developer can extend the default sw-precache behavior to, e.g., implement a specific runtime caching strategy for a specific URL pattern. Or write their own SW push event handlers, which is something that sw-precache doesn't attempt to do at all.

@jpmedley, this is a topic I tried to touch on in Service Workers in Production, but we could use a specific set of guidance in the docs that covers this use case. Something like "sw-precache handles your static resources. To extend your SW to handle other things, use importScripts(...)..." and then some inline examples and a link to the App Shell demo I'm working on, or the Web Starter Kit integration.

[jeffposnick]

This should also explain that editing the generated service worker file is a Very Bad Idea, and if you really need to tweak the generated code, it should be done with using the templateFilePath option.

CC: @addyosmani @gauntface @jpmedley

[webmaxru]

ServiceWorker API is emerging: more and more events to listen appear, much more useful logic could be implemented in SW. So, quite soon it will be default usecase, when sw-precaheis just a part of SW functionality. This is why it's very important to have this flow good explained. For me, it's a bit strange to think about my main shiny SW as about something imported to the utility part of the whole flow. But we can live with it :)

What's important then - is to give all the details about the update issues with importScripts (well described here: http://blog.pushpad.xyz/2016/07/service-worker-importscripts-never-updates-scripts/ ). It's obvious - since your main development happens in the imported file, you will constantly hit these "not updated" issues, so, it's nice to be prepared, and to know the workarounds.

And of course, let's keep an eye on the possible solution: https://github.com/w3c/ServiceWorker/issues/839

[gauntface]

The next incantation of sw-* libraries that this team has been working on will actually be taking steps to give the developer lilbrary that generate the file + revision list and perform the precaching and management that they'd use in their service worker - rather than the current implementation that controls the top-level service worker.

This should allow developer to use this how ever they want.

[webmaxru]

@gauntface do you mean https://github.com/GoogleChrome/sw-helpers ? Because my next question was how is sw-precache aligned with future sw-helpers -> sw-precaching.

[gauntface]

@webmaxru yes I am.

sw-precaching is a module that will do the precaching management (It can be thought of as a wrapped up library of the source-code sw-precaching would include in a service worker). sw-build is a node module that will collect the files to precache and assign a revision.

[webmaxru]

@gauntface thanks for the explanation! I scaffolded a book called "Progressive Web Applications" or just #pwabook, where sw-helpers in the "Nearest future" section at the moment.

[gauntface]

@webmaxru awesome!! Hopefully we'll get it moved over to a chapter soon ;)

[natecox]

Regarding service worker events, wouldn't the general use case be to implement them after registering the service worker in the project-specific code?