#### Repository
https://github.com/BuildTeamDev/tokenbb-web-client

### New Feature

This is part feature, part bug fix, and part mini tutorial, and involves Progressive Web Apps, [Workbox](https://developers.google.com/web/tools/workbox/), and Service Workers, integrating into the [TokenBB](https://tokenbb.io/) project, which uses the [Vue.js](https://vuejs.org/) framework.

The issue initially as stated was as follows. Before this change, there was code in place that used the [cli-plugin-pwa](https://github.com/vuejs/vue-cli/tree/dev/packages/%40vue/cli-plugin-pwa) package to generate a workbox service worker responsible for handling precaching of assets, as documented [here](https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin#generatesw_plugin). In our case, every time a production build is complete, it generates a different service worker. Then on the client side, when the page is loaded, it detects a new version of the service worker is available, installs the service worker in the background. The intent is then that it can prompt the user to refresh to apply the new version of the website.

However, this wasn't happening. We use [register-service-worker npm package](https://github.com/yyx990803/register-service-worker) that manages the life-cycle of the service worker. In our code [here](https://github.com/BuildTeamDev/tokenbb-web-client/blob/master/src/registerServiceWorker.js) you'll see a callback detecting when a service worker is found, applied, and updated in `updated`, and output the log `New content is available; please refresh.`, but refreshing the page did not apply the new content.

Turns out that is because of details concerning the [Service Worker Lifecycle](https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle). Essentially, when a new service update worker is available, it gets installed in the background, but it does not apply until the old service worker is cleaned up. This requires all tabs containing that service worker to be closed down. Specifically, refreshing did not actually accomplish that task, as it does not count as a full close of the tab.

[The Workbox Guides](https://developers.google.com/web/tools/workbox/guides/advanced-recipes) have a recipe for it, but it is *very verbose*. Thankfully the register-service-worker npm condenses a lot of this work. As you'll see in the next section, the task was managed in very few lines, but understanding how all the pieces worked together took me quite a long time. 

Anyway, now we have a nice little  refresh button 

![](https://cdn.steemitimages.com/DQmQK1ZvUyH6YQLNcDeV9eVccLUiXfSkwdV4BXn8dQYEWjb/image.png) 

where pressing it actually updates to the new service worker and new version of the website. Yay.

The upshot here is that it gets rid of the confusion when a new update has gone out but people refreshing the page do not see the update (which was happening up until now :) ). Definitely of interest to @reggaemuffin and @thecryptodrive.

### Code Details

You can find the merged pull request with the highlighted changes here: https://github.com/BuildTeamDev/tokenbb-web-client/pull/28/files

The solution has the following ingredients:

1. Notification with user 'refresh' link to trigger the force install of the new service worker.
2. Addition to service worker to detect the trigger and activate.
3. Set up trigger to reload the page once the new service worker is applied.

[This file](https://github.com/BuildTeamDev/tokenbb-web-client/pull/28/files#diff-ca64b0c7c2def4bcbeea41747d0273a5R24) has the changes for step (3), the reload signal, and step (1), the trigger. Note that it is done via a `postMessage` to the waiting service worker. The nice part about the register-service-worker package is that it encapsulates everything we need to detect the event that the new service worker is ready and waiting, and get access to the waiting service worker to send the message.

The 'skipWaiting' message gets picked up in [this file](https://github.com/BuildTeamDev/tokenbb-web-client/pull/28/files#diff-77341e78c1fb16112d2686c18ff3918eR4) and simply calls "skipWaiting" on the service worker. This allows the waiting service worker to activate immediately and kick out the old service worker. This extra JS is passed in as [an option to workbox](https://github.com/BuildTeamDev/tokenbb-web-client/pull/28/files#diff-0e893b3578ae3d5c8b98bac1c80756a7R5), which we added as a static JS asset to be fetched by the service worker code (For Vue, the build preserves all files in the `public` directory into its bundle).

[This issue](https://github.com/GoogleChrome/workbox/issues/1120) gave a hint for how to augment the service worker generated by workbox and cli-plugin-pwa.

And that's it! It took a long while at first because while chasing around the documentation I didn't realize that I needed to augment the service worker to catch the postMessage (thought it was in the generated service worker). Seems like there's some discussion about that in that referenced issue above.

As usual, let me know if you have any feedback/questions below.

#### GitHub Account

https://github.com/eonwarped