Invalidate cache by service worker

[James2516]

developers (and users) will only see deployed updates on the "N+1" visit to a page, since previously cached resources are updated in the background.

Supposed you have an important update, is there a way to invalidate the cache so that users will see the update on next visit instead of the next + 1 visit?

Is it technically possible to force an automatic browser refresh if the service worker detected that resources are updated, instead of waiting until the next visit to display them?

[piotr-cz]

It's possible to add a callback with a refresh (or notification with refresh button) after app has been updated, see my #3375

[rclai]

Any progress on this? I've been snagged by this issue thinking it was an nginx issue but it wasn't and I'm not a fan of telling my users to reload twice to see the newest updates.

[rclai]

Nevermind, found out I can opt out of service worker caching in the read me.

[gaearon]

cc @jeffposnick

[jeffposnick]

If #2426 were merged, it would add a standard way of prompting users to reload whenever there's an updated to a precached resource.

If you wanted to "take matters into your own hands", and automatically force a refresh whenever there's updates to precached resources, you could modify the code at https://github.com/facebookincubator/create-react-app/blob/72b6eb8c3c65e6ed0f2413708069287311a386c2/packages/react-scripts/template/src/registerServiceWorker.js#L63-L69

and replace the console.log() statement with window.location.reload(). This is not necessarily the best user experience, though, since the reload might happen in the middle of a user interacting with the page, and they might find it disconcerting for everything to disappear and then quickly reappear.

[James2516]

Perhaps an extra optional parameter (taking constants exported from registerServiceWorker.js) to register() that determines the different behaviours:

1. current behaviour (default)
2. standard prompt to reload
3. automatic reload
4. extra callback parameter to customise response (maybe call the callback both before and after successful reload with a status parameter)

Also, is it possible to insert metadata to the updated content to inform the service worker on what action to take for that particular update? Perhaps another contentInfo parameter on behaviour 4?

Eg. I could insert a mandatory flag to the new content and sw would force automatic reload if this flag exists in that update.
This might lead to some complications though (eg. all updates after the mandatory update should behave the same as mandatory even if the flag is not present if the user "bypassed" the mandatory update).
Similar to https://github.com/Microsoft/code-push/blob/master/cli/README.md#mandatory-parameter

[jeffposnick]

Some of that feedback would be best directed towards #2426, which would need to be updated to match what you describe.

Regarding passing along additional information about which URLs were updated, that's unfortunately not something that's exposed in the current, sw-precache-based approach to caching. (It is something that's supported in the newer Workbox library; see #2340 for a discussion of that.)

[stale]

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