Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalidate cache by service worker #3665

Closed
James2516 opened this issue Dec 31, 2017 · 8 comments
Closed

Invalidate cache by service worker #3665

James2516 opened this issue Dec 31, 2017 · 8 comments

Comments

@James2516
Copy link

James2516 commented Dec 31, 2017

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
Copy link
Contributor

piotr-cz commented Jan 2, 2018

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

@rclai
Copy link

rclai commented Jan 3, 2018

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
Copy link

rclai commented Jan 3, 2018

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

@gaearon
Copy link
Contributor

gaearon commented Jan 9, 2018

cc @jeffposnick

@jeffposnick
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link

stale bot commented Nov 2, 2018

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.

@stale stale bot added the stale label Nov 2, 2018
@Timer Timer closed this as completed Nov 2, 2018
@lock lock bot locked and limited conversation to collaborators Jan 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants