topaxi / ember-service-worker-update-notify Goto Github PK

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?

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.

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

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.

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.

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

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

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!

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.

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:

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.

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

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