7

I found this repo describing HOW to destroy a service worker. But I didn't find any resources describing WHEN a worker should destroy/uninstall/unregister itself.

When I develop websites, I often use port 8080. I can be working on site X that has a service worker, then work on site Y that doesn't have a service worker but the original and now incorrect service worker persists.

The logic for a service worker deciding to uninstall itself is a bit tricky because we want to:

  • Allow the service worker to work offline.
  • Allow the service worker to survive a captive wifi portal.
  • Detect the browser is online but this site should not have a service worker, or that the service worker should be a different one.

Is there a standard mechanism or convention around this?

ubershmekel
  • 11,864
  • 10
  • 72
  • 89
  • 1
    https://redfin.engineering/how-to-fix-the-refresh-button-when-using-service-workers-a8e27af6df68 may help if u review that one – Robert Rowntree Jan 03 '20 at 16:37

2 Answers2

4

The simple answer is that normally it would never destroy itself.

This seems to be a problem for you as you are developing multiple sites and then testing them all as localhost:8080.

Their are a few ways to address this particular problem:

The first would be to set up aliases for each site you develop in /etc/hosts.

127.0.0.1  local.site-a.com
127.0.0.1  local.site-b.com

Another option is to configure each project to run on a different port when testing.

The last option would be to include the code you linked to in your question, in each project that does not have a service worker. Although would this approach you would then ideally need to make your build process only include it in Dev builds.

David Bradshaw
  • 11,859
  • 3
  • 41
  • 70
  • I think a site that's in production might have a service worker, and a new version of it might not. In that case, it would be a pain to figure out and fix after the fact. That's why I can't accept this as an answer, it doesn't solve the problem. – ubershmekel Jan 09 '20 at 02:06
  • That is the use case for the script you linked to in your question – David Bradshaw Jan 09 '20 at 08:15
  • 1
    @ubershmekel Maybe you should edit your question to give a clearer context, if you don't accept the answer. – Akinjiola Toni Jan 10 '20 at 10:25
  • I asked "when should a service worker self destruct?" and this answer is claiming "never" or "manually". It would be a valid answer if it were absolutely the only way, but I believe there can be an automated self-destruct solution. – ubershmekel Jan 10 '20 at 17:07
1

you have to register a javascript file in serviceworker which checks the local path of site X before running your javascript file.

navigator.serviceWorker.register('/checking.js').then(function(registration) {
  // Registration was successful
  }

In checking.js

if(window.location.href == "YOUR X SITE FILE PATH"){
 //Run the javascript file which you have created for site X 
}

Remember during production you have to change the parameter of serviceWorker() to your respective js file

Akash Badam
  • 476
  • 2
  • 9
  • I'm not sure what you mean by `the parameter of serviceWorker()` and I'm not sure what in your answer would cause the service worker to trigger self destruction (`unregister` and refreshing the pages). – ubershmekel Jan 10 '20 at 17:15
  • https://developers.google.com/web/fundamentals/primers/service-workers here it says that serviceworker will terminated when it is not in use. So by checking the local path of your site X you have to run service worker only then. – Akash Badam Jan 10 '20 at 18:03
  • 1
    https://stackoverflow.com/questions/49740931/unregistering-removing-a-service-worker you can check this for unregister the serviceworker if you are using site Y or any else sites – Akash Badam Jan 10 '20 at 18:12