-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
Whitelist files from service worker caching #4674
Comments
I think this is related: #3171 |
Hey! I really appreciate this writeup, but we're no longer suggesting service workers as a default because there's too many problems with them in a zero-config setup. We'll look at bringing them back in a few years when the community has settled around a common set of tools & configuration for them. Service workers will be removed from the next major version of CRA. Thanks much! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The default service worker intercepts everything except "cross-origin traffic, like HTTP API requests, images, or embeds loaded from a different domain." This is generally great for allowing my app to work offline. I ran into one use case that is problematic with this, however: RSS feeds.
My RSS feeds are generated in the back-end. Unlike API requests, users usually visit an RSS feed directly in their browser before subscribing to it (at least in Firefox). However, instead of seeing the feed in Firefox's usual RSS feed interface, the user gets served
index.html
(with the 404 route) from the service worker cache.I think this is a valid use case for overriding the default cache. Furthermore, it could be implemented without changing the default behaviour, by allowing the developer to specify a specific list of files that can be whitelisted from caching, which could be passed to
sw-precache
'snavigateFallbackWhitelist
option as a regexp of URLs not to match. The main consideration would be whether this configuration option would add too much complexity. On the one hand it's another option, on the other hand ejecting feels somewhat heavy-handed for this, and there are already sections in the README about opting out of caching and considerations to keep in mind related to intercepted requests (point 7).Let me know whether this would fit the project - I could look at preparing a pull request.
Which terms did you search for in User Guide?
Cache
feed
service worker
rss
whitelist
The text was updated successfully, but these errors were encountered: