Friendly reminder to bake a kill switch into your service worker code before shipping to production. I've used mine twice now 

-
-
Ahhh, this would need server-side support as well right?
-
Definitely - seems a bit more complex for benefits I can't yet see.
-
In your case, I'm still unclear on how you as a dev would trigger the kill switch for some end user? I couldn't figure out from the code
-
You realize there's a problem with the sw, you flip the kill switch, commit, and deploy. Next time user hits your site, sw will die.
-
Ahhhh, got it! Thanks for explaining.

-
I would avoid depending on "kill switch" logic in `window` context, since it doesn't help when you deploy a SW that prevents your `window` context code from running. https://stackoverflow.com/a/38980776/385997 … is a pattern of shipping new SW code to the existing URL to "neuter" the previous bad SW.
-
> doesn't help when [...] a SW that prevents your `window` context code from running I must be missing something. If that's a concern, how can you be sure the `serviceWorker.register` line will execute, and get updated sw.js? Doesn't the register line execute in window context?
-
The concern is that after your client-side code initially registers a SW, the SW takes controls and responds to future navigation requests with garbage HTML. That prevents your client-side code from executing again. The SW script update check will still happen in that scenario.
End of conversation
New conversation -
-
-
Really like this one. Good thinkin. Cc:
@adamdbradley good thread on SW kill switch. Worth a readThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.