How to display a “new version available” of your Progressive Web App
This is a good walkthrough of the flow you’d need to implement if you want to notify users of an updated service worker.
Ooh, this is a tricky scenario. If you decide to redirect all URLs (from, say, a www
subdomain to no subdomain) and you have a service worker running, you’re going to have a bad time. But there’s a solution here to get the service worker to remove itself.
The server-side specifics are for NGINX but this is also doable with Apache.
This is a good walkthrough of the flow you’d need to implement if you want to notify users of an updated service worker.
It is very disheartening to read misinformation like this:
A progressive web app is an enhanced version of a Single Page App (SPA) with a native app feel.
To quote from The Last Jedi, “Impressive. Everything you just said in that sentence is wrong.”
But once you get over that bit of misinformation at the start, the rest of this article is a good run-down of planning and building a progressive web app using one possible architectural choice—the app shell model. Other choices are available.
Hmm …seems like I should probably wait for the load
event before triggering navigator.serviceworker.register()
.
Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…
In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.
I’m hopeful that future iterations of React will make this a smoother option.
Pour one out for rel=”serviceworker”
Back-end development isn’t the same as front-end development.