Skip to content
This repository has been archived by the owner on Jan 23, 2021. It is now read-only.

Better explanation of how importScripts can extend default behavior #49

Open
jeffposnick opened this issue Nov 2, 2015 · 8 comments
Open

Comments

@jeffposnick
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

webmaxru commented Mar 5, 2017

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: w3c/ServiceWorker#839

@gauntface
Copy link

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
Copy link

webmaxru commented Mar 6, 2017

@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
Copy link

@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
Copy link

webmaxru commented Mar 7, 2017

@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
Copy link

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

@natecox
Copy link
Contributor

natecox commented Mar 7, 2017

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants