Chrome Extension Service Workers
Learn what a chrome extension service worker is, what the service worker lifecycle is, and how to respond to events with service workers.
Table of Contents 📖
- What is a Service Worker?
- Service Workers and the DOM
- Working with Service Workers
- Service Worker Life Cycle
- Service Workers and Storage
What is a Service Worker?
A chrome extension service worker is an extension's central event handler. They respond to events such as closing a tab, network calls, navigating to a new web page, etc. They are loaded when they are needed and unloaded when they are not. In other words, they run as long as they are receiving events.
Service Workers and the DOM
It is important to note that service workers are run in a worker context, which means they cannot access the DOM. In fact, service workers run on their own thread, so they won't block the main thread that does interact with the DOM. Because of this, service workers perform non-blocking operations and are completely asynchronous.
Working with Service Workers
To work with chrome extension service workers, they first need to be registered. To do this, we need to provide a single JavaScript file to the service_worker key, under the background key, inside manifest.json.
"background": {
"service_worker": "my-service-worker.js"
},
The background key specifies scripts/processes that will be ran in the background, the service_worker key accepts a single JavaScript file. Here, we are telling Chrome that we have a JavaSctipt file called my-service-worker.js that will be ran in the background. Now, lets create this my-service-worker.js file.
touch my-service-worker.js
Service Worker Life Cycle
Chrome extension service workers follow a life cycle. The main steps of this life cycle are installation, startup, and shutdown. It is useful to know these events as we can tap into them and perform tasks at the appropriate time. For example, during the installation stage the chrome runtime onInstalled event is fired.
chrome.runtime.onInstalled.addListener(() => {
console.log('Extension installed, updated to a new version, or Chrome is updated to a new version.')
});
This event is fired when the extension is first installed, updated to a new version, or when Chrome is updated to a new version. Therefore, this event is a great spot to do some one-time initialization. Another example is the onStartup event which occurs during the startup phase of the life cycle.
chrome.runtime.onStartup.addListener(() => {
console.log('User profile that has this extension is installed has first started up!');
});
This event is fired when the user's profile that has the extension installed starts up. Finally, we have the idle and shutdown stage of the service worker lifecycle. Service workers are dormant until an event is fired. When an event is fired the service worker handles the event, if it has the appropriate handler, and then goes dormant again. Specifically, service workers shut down after being idle for 30 seconds. As such, network calls initiated by a service worker that take longer than 30 seconds will fail as the service worker handling the response would be shut down. However, any interaction with the Chrome extension API causes this 30 second timer to reset.
Service Workers and Storage
As service workers go idle and shut down, global variables will be lost when the service worker shuts down. Therefore, it is never a good idea to use the global namespace of a service worker for storage. Inatead, APIs such as the Chrome storage API should be used.