topaxi/ember-service-worker-update-notify

Update notification for service workers

ember-service-worker-update-notify

Adds a service-worker-update-notify service and <ServiceWorkerUpdateNotify /> component which displays a reload link if the service-worker has found an update.

Usage

Using the component

The component will show a message to the user when the availability of an update has been detected. Overwrite the default message using the component in block form:

<ServiceWorkerUpdateNotify>
  <a class="service-worker-update-notify" href={{this.router.currentURL}}>
    A new version is available, click here to update.
  </a>
</ServiceWorkerUpdateNotify>

Using the service

The service allows you to react to an app update in a more programmatic manner, e.g. you could force reload the app. The service emits an update event once an update has been detected. Here is an example of an application route that reloads the app automatically:

import Route from '@ember/routing/route';
import { inject as service } from '@ember/service';

export default class ApplicationRoute extends Route {
  @service
  serviceWorkerUpdateNotify;
  
  beforeModel() {
    this.serviceWorkerUpdateNotify.on('update', () => {
      window.location.reload();
    });
  }
}

Configuration

The poll interval can be configured in your config/environment.js with:

module.exports = function(environment) {
  let ENV = {
    'ember-service-worker-update-notify': {
      pollingInterval: 1200000 // Default is 20min
    }
  };

 return ENV;
};

Testing in Your App

Testing this in your app should mainly be concerned with presence and and what it looks like.

During testing, the polling will be disabled, and the reveal of the "New version available" content is controlled by a promise set on the window. In your tests, two helpers will aid you in asserting presence and appearance: setupServiceWorkerUpdater, and hasServiceWorkerUpdate.

// ...
import {
  setupServiceWorkerUpdater,
  hasServiceWorkerUpdate
} from 'ember-service-worker-update-notify/test-support/updater';

module('Application | Index', function(hooks) {
  setupApplicationTest(hooks);
  setupServiceWorkerUpdater(hooks);

  test('the update is shown', async function(assert) {
    // assert that the content is not shown

    await serviceWorkerUpdate();

    // assert that the content is shown

  });
});

Installation

yarn add --dev ember-concurrency # peer-dependency
yarn add --dev ember-service-worker-update-notify

Local installation

• git clone <repository-url> this repository
• cd ember-service-worker-update-notify
• npm install

Linting

• npm run lint:hbs
• npm run lint:js
• npm run lint:js -- --fix

Running tests

• ember test – Runs the test suite on the current Ember version
• ember test --server – Runs the test suite in "watch mode"
• ember try:each – Runs the test suite against multiple Ember versions

Running the dummy application

• ember serve
• Visit the dummy application at http://localhost:4200.

For more information on using ember-cli, visit https://ember-cli.com/.

License

This project is licensed under the MIT License.

ember-service-worker-update-notify's Issues

Realtime update

Service workers install in realtime (I think), so this update should be realtime as well.
This will urge users to not work with a outdated app and prevent errors/bugs.

Testing without deploying

Is there a simple way to test this notification without deploying?

Should not register a SW if ember-service-worker is disabled

Hi, first of all thanks for this addon! Works great!

In ember-service-worker it's possible to disable the registration of the SW using the option enabled: false

One little problem I found is that if ESW is disabled, this plugin keeps trying to register the SW anyway: https://github.com/topaxi/ember-service-worker-update-notify/blob/master/addon/services/service-worker-update-notify.js

This can lead to some weird behaviour.

Show update notification immediately after start up

If user start the app with an outdated version, he won't see an update notification before pollingInterval is over. This seems to be intended:

ember-service-worker-update-notify/addon/components/service-worker-update-notify.js

Lines 16 to 19 in 341371d

	/**
	* Delay attaching the updateHandler to prevent users from
	* seeing a new build notification immediately on page load.
	*/

This doesn't fit my use case well. I want to show the user a notification as soon as possible. This is also what I'm used to from other apps (e.g. CodeSandbox). It would be nice, if we could configure the initial delay.

A non-breaking change would be introducing a initialDelay configuration option that defaults to pollingInterval. But I'm not sure if the current behavior is a reasonable default. I would image that most applications want to inform the user about an update being available as soon as possible.

Remove default component content

I would assume that virtually no one ever uses the default content that comes from the component here: https://github.com/topaxi/ember-service-worker-update-notify/blob/master/addon/templates/components/service-worker-update-notify.hbs#L5, for either using custom markup, different wording, i18n or whatelse. So instead of shipping those few extra bytes of IMO useless template code (admittedly not much), I would suggest to remove that and only support the current block mode.

This could be done as part of the major release required for #20 anyway.
Thoughts? @topaxi @NullVoxPopuli

Support for Ember 4.x

Issue: Uncaught (in promise) ReferenceError: Ember is not defined

A note on testing

with the latest version of esw-update-notify,
you need to not check for updates in acceptance tests.

because all your tests will be delayed by the polling interval.
Not sure what could be a better solution atm.

Triggers on refresh with latest build

Hi guys, great addon thanks!
Just have a quick question, all works as expected, but if i refresh the app myself before the polling has happened (so I have the latest source) it still triggers the update notifcation, even though its not necessary. Am I maybe doing something wrong?

Ofcourse this wont necessarily be a problem in practice as the client would know either way, but still seems redundant to me.

Thanks!

Question about first time visitors

Hello, this addon is great! I just have a quick question...

First time visitors, after the polling interval... should see the notification to reload? In my logic, that's unexpected, because in this particular case the sw.js they registered when they first enter (just now), is the last up-to-date sw.js

This is happening to me now, and well I just want to be sure its the expected behavior

Not working in octane app

Repro repo: https://github.com/fpauser/esw-test

Running with ember s --live-reload false. When triggering a rebuild by saving/rewriting e.g. application.hbs I would assume that the <ServiceWorkerUpdateNotify> component should come up with the update message - which does not happen.

While building this message from babel appears:

building... [Babel: ember-service-worker-update-notify > applyPatches]The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten

Polling prevents settledness in tests

The polling task prevents await settled() (or any other related test helpers waiting for settledness) to occur. Not only in the tests of this addon (see https://github.com/topaxi/ember-service-worker-update-notify/blob/master/tests/acceptance/usage-test.js#L45-L47), but also in any app that uses the addon it seems.

As the current test infrastructure does not really test the polling part, but short-cuts the update detection (see #20 (comment)), I think we could just move the Ember.isTesting guard before the polling task, not not perform it at all in tests.

Will come up with a PR, that we can discuss, after #20 is merged.

Failed to find a valid digest in the 'integrity' attribute for resource

I am using this addon in combination with;

• Ember Service Worker
• Ember Service Worker Asset Cache
• Ember Service Worker Index

When we do a new deploy to our server, we override the old static assets with the new static assets from a fresh ember build --environment=production

This correctly triggers a Update Notify message to pop up.
But after clicking the message, the application reloads, and we're getting an error saying:

Failed to find a valid digest in the 'integrity' attribute for resource

And the application does not load anymore, and we are stuck on a white screen of death.
Doing a hard refresh of the page in the browser (Ctrl - Shift - R), fixes the issue and everything works again.

This however is not desirable UX behavior. Are we doing anything wrong? Or is there a bug I can help fixing?