Service Worker API allows Web developers to offer visitors something previously unattAInable: access to websites or web applications even when they’re offline, whether for short or extended periods. Whether you want to ensure your visitors can still read your site while on a train through a tunnel or create an app that doesn’t require an internet connection, service workers provide the perfect solution.
Though service workers are exceptional, there can be initial hurdles when you start coding with them, unless you’re aware of these obstacles beforehand. This tutorial offers five fundamental tips for service worker development that we Hope will help you avoid these issues and spare you from related troubleshooting hassles.
Before we begin, if you’re new to service workers, check out our beginner’s course, “Simple Service Worker for Offline Websites,” and Jeremy Keith’s book, “Going Offline,” both available at Environment Factors.
1. Place Your Service Worker in the Root Directory
One of the earliest issues you might encounter when writing your first service worker is to put your script in a typical ‘js’ or ‘scripts’ subdirectory. However, this common practice might cause problems for service workers. The reason is that by default, a service worker’s scope is defined by its location. This means that if you place your script in the ‘/js’ directory, its scope is now limited to that directory only. It can only handle page requests from www.yoursite.com/js/ and ignores others like www.yoursite.com or www.yoursite.com/news/. This limited scope, in turn, means you won’t be able to provide offline fallbacks for most of your site’s content. To make your service worker capable of handling requests from any part of your site, its scope must be all-encompassing.
Note: You can actually override a service worker’s default scope during registration, e.g., `navigator.serviceWorker.register(‘/SW.js’, { scope: ‘/’ });`. This way, if it’s crucial for your project, you can still store all scripts in subdirectories. But generally, the simplest approach is to keep your service worker in the root directory, automatically setting its scope to cover the entire site.
2. Use the Chrome/Chromium Developer Tools’ Application Panel
While service workers are supported by all major browsers, Chrome or Chromium could be considered the best browser for developing them, thanks to the very useful Application panel in the Developer Tools. You’ll practically live in this tab during the development process.
Here, there’s a dedicated section for service workers where you can Verify if your script is registered, active, and running. You can also use this tab to simulate offline status, bypass the service worker thread temporarily, and manually unregister scripts no longer needed.
3. Avoid Hard Reloads
Another development habit to break when combining with service workers is using “Hard Reload” or “Clear Cache and Hard Reload.” You might have done this thousands of times while testing sites, using the feature to clear the cache and ensure an accurate reflection of your development changes. But with service workers, this won’t yield the desired effect.
When you have a registered and active service worker, using “Hard Reload” completely bypasses it. You might hard-reload your site, see your code not behaving as expected, and think you made a mistake, only to realize later that the script never ran in the first place.
Therefore, “Hard Reload” and “Clear Cache and Hard Reload” are out of the question during service worker development, leading us to the next issue:
How can you correctly refresh the page and test your service worker code? If you can’t use “Hard Reload” or “Clear Cache and Hard Reload,” what changes?
The answer lies in the following two tips:
4. Check the “Update on Reloader” Box
By default, when you refresh a page while Testing a service worker, you won’t see the results of any code changes. This is because the version of the script you initially registered remains active in the browser, even after a page reload, unless you take explicit Action to update it.
So, you might be refreshing your page and wondering why your code changes aren’t taking effect, unless you understand the quirks of service workers. To ensure the latest version of the script always loads, go to the Application tab and check the “Update on Reloader” box. This ensures that the browser will automatically update the service worker each time you reload the page (remember, using a normal reload, not a hard one).
5. Inspect and Manually REMOve Cache Objects
The last very convenient feature we touch upon in the Application panel is the ability to view objects stored in the cache and delete them manually as needed. Considering we don’t want to use “Clear Cache and Hard Reload,” this feature will be a significant part of your service worker development process.
In the left sidebar of the Application tab, you’ll find an area labeled “Cache Storage.” Expanding this area will show any cache objects saved related to the current URL.
Clicking on any item lets you inspect its content, which is helpful for verifying that the resources you want for offline service are correctly added to the cache by your service worker.
To delete a no-longer-needed cache object, simply right-click it and choose “Delete.”
With this cache object deletion feature and the “Update on Reloader” checkbox, you’re set to stick with regular page reloads while still ensuring you properly test your latest changes.
Summary:
– Place service worker script in the root directory so the entire site falls within its scope.
– Use Chrome/Chromium’s “Application” tab during development.
– Avoid “Hard Reload” or “Clear Cache and Hard Reload.”
– Check the “Update on Reloader” box in the Application tab to ensure the registered service worker is the latest.
– Inspect and manually remove cache objects as needed via the “Cache Storage” section in the Application tab. You can also check cache object contents here.
For more information on service workers, explore our new course, “Simple Service Worker for Offline Websites,” and Jeremy Keith’s book, “Going Offline,” both available at Environment Factors. Stay tuned to Host Reference for more related articles!
相关文章
