Created by: ro-savage
Addresses some of the issues raised in #2398 (closed)
Specifically, that service workers are
- Showing the wrong page when a non-CRA app is hosted at the same url + port, with manually deleting the SW the only way to fix it.
- Showing an old CRA project if you are hosting a new on at the CRA on first visit. When refreshed the new project will show.
This adds the following checks when using service workers to fix these issues
- Check if service worker already exists
- If no service work, add service worker
- If service worker is found, check the serviceworker url.
- If its finds a 200 ok at the url. Then use the service worker as normal. (Same app)
- If it doesn't doesn't get a 200 ok. Then check if the domain is working.
- If domain responses with 200 ok. Then remove service worker and refresh the page (different app)
- If anything else. Assume domain or user is offline and used service worker to provide cache.
For this to work properly, we'd need to give the service-worker.js a unique name such as service-worker-[projectname].js. This way each project as a unique service worker URL and we can tell if we are using the correct service worker.
For the webpack setup, we can just create a customer name for the generated the service worker using (service-worker-${packageName}].
For the registerServiceWorker.js we create an environment variable that contains the projects package.json name, and use this to know the right file to look for.
@gaearon @Timer @jeffposnick - Any ideas how we can name/rename the service-worker.js?
-
Make it work -
How to correctly name service-worker.js -
Think of edge cases and how to handle them - Currently handles offline and website down -
How big is the slowdown in using fetch before we load the service worker? Especially if we are offline. -
Is the a quicker way to tell if a device is offline? If offline we should catch immediately -
Tests? -
Are there other ways to deterministically tell what project a cached service worker is attributed to?