You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 23, 2021. It is now read-only.
The current release of sw-precache has a very rudimentary "routing" system in place, in which navigations to either all URLs or just URLs that match a set of RegExps will result in the App Shell HTML, via the navigateFallback and navigateFallbackWhitelist options.
This works well enough for sites that only have a single App Shell within the scope of their service worker, but it would break down when there are multiple App Shells that might be used for different URL routes.
Something more flexible allowing arbitrary route-to-App Shell mappings would allow for more complicated web app setups.
And then it may or may not make sense to combine this routing with the routing rules used to define sw-toolbox runtime caching via the runtimeCaching option.
The current release of
sw-precache
has a very rudimentary "routing" system in place, in which navigations to either all URLs or just URLs that match a set ofRegExp
s will result in the App Shell HTML, via thenavigateFallback
andnavigateFallbackWhitelist
options.This works well enough for sites that only have a single App Shell within the scope of their service worker, but it would break down when there are multiple App Shells that might be used for different URL routes.
Something more flexible allowing arbitrary route-to-App Shell mappings would allow for more complicated web app setups.
And then it may or may not make sense to combine this routing with the routing rules used to define
sw-toolbox
runtime caching via theruntimeCaching
option.CC: @addyosmani @gauntface @wibblymat for thoughts.
The text was updated successfully, but these errors were encountered: