Handling Service Worker

Here you'll learn how to interact with the Service Worker from within your website/app space. Remember, service workers MUST be served over HTTPS.

It's important to note that the Service Worker (which gets automatically generated by Workbox -- or you've configured Quasar CLI to use your custom one) runs in a separate thread. You can however interact with it from app-space from within /src-pwa/register-service-worker.js file.

Interacting with Service Worker

Add the register-service-worker npm package in your package.json file as a dependency (if it's not already there).

import { register } from 'register-service-worker'

register(process.env.SERVICE_WORKER_FILE, {
  ready (registration) {
    console.log('Service worker is active.')
  },

  registered (registration) {
    console.log('Service worker has been registered.')
  },

  cached (registration) {
    console.log('Content has been cached for offline use.')
  },

  updatefound (registration) {
    console.log('New content is downloading.')
  },

  updated (registration) {
    console.log('New content is available; please refresh.')
  },

  offline () {
    console.log('No internet connection found. App is running in offline mode.')
  },

  error (error) {
    console.error('Error during service worker registration:', error)
  }
})

::: tip This file is automatically bundled into your website/app by Quasar CLI because it is considered as part of app-space /src. What this means is that you can use ES6, import other files etc. :::

SSL certificate

You may notice in some dev environments, that Workbox will not load your service workers during quasar dev if you are not using HTTPS to serve - even on localhost. You may see that there are two scripts that can't load. The Chrome browser console is relatively tight-lipped about this, but Firefox tells you what is going on. The three options you have are:

• set quasar.config file > devServer > https: true
• setup a loopback from localhost to 127.0.0.1 (but this is not without security implications)
• serve your localhost over tunnelmole, localhost.run or ngrok and use the https address provided by them.

Here is a tunnelmole example (install it first with yarn global add tunnelmole or npm i -g tunnelmole):

$ tmole 80
http://b8ootd-ip-157-211-195-182.tunnelmole.com is forwarding to localhost:80
https://b8ootd-ip-157-211-195-182.tunnelmole.com is forwarding to localhost:80

# ...and use the HTTPS url shown in the output

When you set devServer > https: true in your /quasar.config file, Quasar will auto-generate a SSL certificate for you. However, if you want to create one yourself for your localhost, then check out this blog post by Filippo. Then your quasar.config file > devServer > https should look like this:

devServer: {
  server: {
    type: 'https', // NECESSARY

    options: {
      // Use ABSOLUTE paths or path.join(__dirname, 'root/relative/path')
      key: "/path/to/server.key",
      pfx: "/path/to/server.pfx",
      cert: "/path/to/server.crt",
      ca: "/path/to/ca.pem",
      passphrase: 'webpack-dev-server' // do you need it?
    }
  }
}

Important Hosting Configuration

It's important that you do not allow browsers to cache the Service Worker file (by default: sw.js). Because otherwise updates to this file or to your app might slip through the cracks for browsers that load the service-worker from cache.

This is why you must always make sure to add "Cache-Control": "no-cache" to the headers of sw.js file via your hosting service.

As an example how this is done for Google Firebase, you would add the following to the firebase.json configuration:

{
  "hosting": {
    "headers": [
      { "source":"/sw.js", "headers": [{"key": "Cache-Control", "value": "no-cache"}] }
    ]
  }
}