Make onUpdate callback fire when a new service worker is intalled and waiting

[arackaf]

Simple change to have the onUpdate callback fire when a newly installed service worker is waiting. This ensures the notification will not just come the first time the sw is updated, but rather each refresh until it takes over.

The modified code was run in my local project, and the onUpdate did continue to show on each refresh until all tabs were closed, and the new sw took over.

[Timer]

/cc @jeffposnick

[dominicarrojado]

How to do force the update without closing all tabs? How to implement skipWaiting with CRA?

[arackaf]

That has to be done client side. skipWaiting would be called in the callback you provide for onUpdate, which would then post a message that client side code would have to receive, and then manually refresh.

[dominicarrojado]

But the event listener for the message to skipWaiting should be on the service worker file which is only available after build. Is there a way without touching the build files?

[arackaf]

To automatically have service workers skipWaiting, you’d need to override the sw configuration using something like customize-cra

[dominicarrojado]

@arackaf Thank you, that's exactly what I need.

[jeffposnick]

I chatted with @arackaf about this logic and it looks 👍

Thanks for putting the PR together!

[petetnt]

Neat PR!

This bit.ly link needs to be pointed to https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app now. I created http://bit.ly/CRA2-PWA but not sure if @gaearon wants to do it from his own account or something similar :)

[iansu]

There are some issues with updating these links as these files (with the original links) are present in existing projects. More details here: #5536

[petetnt]

ah, I see. Thanks.

[arackaf]

done!

[arackaf]

@jeffposnick - just tweaked things to pass the updated sw to the onUpdate callback, so client code can postMessage to it.

Anything blocking this from getting merged?

[tyler-dunkel]

@arackaf regarding your statement about automatically skipWaiting for SW.... does this mean to have the behavior of: "code has changed, have user refresh current tab for new content" would need the customization of c-r-a? I.E. does that mean that C-R-A only supports updating content from a SW by closing the tab and reopening the app in a new tab?

[arackaf]

“closing and reopening the tab”

Yeah, by default that’s what the user has to do to get the new sw. Once this pr is merged you’ll be able to do something like this

https://twitter.com/adamrackis/status/1060036913921449984?s=21

[Timer]

Can you update the TS version too, please?

[arackaf]

@Timer sorry? There's a TS version of this same file? Where?

[tyler-dunkel]

@arackaf Thanks for the quick answer! one other question if you dont mind: what does this mean in the context of installed apps on mobile homescreens?
i.e. if an android user has added the app to homescreen, do they need to kill the running process to get the updated content?

Also, regarding the tweet you shared, I see that part of that solution involves updating the service-worker file itself to add the message event handler. So this would require using something to customize C-R-A's generated service-worker file?

[Timer]

https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template-typescript/src/serviceWorker.ts

[inssein]

@arackaf this PR only makes sense once you can customize you service worker to skip waiting. I saw your tweet, but don't understand where the code in the third screenshot is placed.

[NShahri]

I am trying to describe 2 scenarios which can be used in PWA app to show message, reload the app UI
and install new service worker:

• CASE 1: using skipWaiting config of WorkBox of WebPack plugin
  When user reopened the page or after update method has been called, state of new service worker would change to installed first and activated afterwards, but the app UI would be old one. Showing a message which tells a user to reload the page would be useful.

• CASE 2: no skipWaiting config for WorkBox
  Based on Advanced Recipes, we can trigger skipWaiting and reload the page when service worker gets activated(not sure how it is possible with WorkBox Webpack Plugin), but in this method we can minimise time between updating service worker and updating UI.

Requirements:

• CASE 1 requirements:
  • onUpdateActivated event/callback
• CASE 2 requirements:
  • onUpdateAvailable event/callback
  • onUpdateActivated event/callback

onUpdateAvailable/onUpdate callback
It is exactly current onUpdate implementation.

onUpdateActivated/onActivated callback
It can be implemented in one of these ways:

navigator.serviceWorker.addEventListener('controllerchange’, ()=>{})

OR

registration.installing.onstatechange = () => {
if (registration.installing.state === ‘activated’) {}
}

[arackaf]

@inssein screenshot #3 is code that you manually wire into the service worker via importScripts, via workbox configuration

https://github.com/arackaf/booklist/blob/master/react-redux/webpack.config.js#L116

[arackaf]

@Timer sorry for the delay - how's that look?

[inssein]

@inssein screenshot #3 is code that you manually wire into the service worker via importScripts, via workbox configuration

https://github.com/arackaf/booklist/blob/master/react-redux/webpack.config.js#L116

You can't do that without ejecting though, right?

[arackaf]

@inssein - ah, sorry, no need to eject - just a lil tweak is all you need :)

https://github.com/arackaf/customize-cra#adjustworkboxfn

[samccone]

@gaearon Hey Dan, anything I can do to help move this along? This is a major win to those of us out there that are using CRA + SW integration.

Thanks so much for your time and please do let me know what I can do to help.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[danielkcz]

Well, this is getting kinda sad. This thing is working quite nicely, I have it in a production of two apps. Not sure why it's being held back so badly.

[dominicarrojado]

Yeah, same here as well. I also used this for my apps.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[danielkcz]

Here we go again :) Stale bot, go away!

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[arackaf]

Any reason this was never merged?

[iansu]

@arackaf No, I don't think there was a reason. It just fell through the cracks while we were working on 3.0. We'll take a closer look at it and see if we can get it into an upcoming release.

[arackaf]

Sweet, thanks! Sorry if my comment came off as snarky - I just needed something so the bot wouldn't close, and that's what my brain tossed out :)

[iansu]

That's actually one of the nicer responses to the stale bot that I've seen. 😀

[FezVrasta]

Should you merge it?

[andriijas]

@arackaf thanks for your patience. could you rebase your branch on top of the latest changes?

thanks

[arackaf]

Not really. It's been years since I even looked at this. I'd recommend just merging and pushing.

[andriijas]

That was my idea. I had some time over today and have been working through long running PRs. Given this was already approved I wanted to get it in however there are conflicting files.

I understand your frustration. Just let us know if you want to give it one more time or if we should close this or if there is someone else who can continue.

Sorry for any inconvinience

[arackaf]

Yeah it's been years since I even looked at this project. I wouldn't really feel comfortable trying to resolve conflicts, nor am I in a position to test the resuls easily.