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
According to the motivation, I seem our ideal status resolved by this API is ServiceWorker works as opt-in mode if a user code calls event.addRoutes().
I think almost combinations of RouterRule would be nice to work like opt-in semantics. However, there are some cases that are not intuitive combinations.
// This example is cited from the explainer.// I think this shows opt-out behavior semantics.// -----// Go straight to the network and bypass invoking "fetch" handlers for URLs that start// with '/videos/' and '/images/'.addEventListener('install',(event)=>{event.addRoutes([{condition: {urlPattern: newURLPattern({pathname: "/images/*"})},source: "network"},{condition: {urlPattern: newURLPattern({pathname: "/videos/*"})},source: "network"}]);});
On the other hands, if RouterRule.source is "fetch-event” or cache, ServiceWorker would work like as opt-in for registered conditions by the spec.
// By the current spec, this indicates ServiceWorker should wake up// and intercept for URLs with `/assets/`. I seem this shows opt-in behavior semantics.addEventListener('install',(event)=>{event.addRoutes([{condition: {urlPattern: newURLPattern({pathname: "/assets/*"})},source: "cache"},
If I don't misunderstand the spec, I think this API semantics inconsistency may confuse a developer.
Idea
I also propose a rough idea to resolve this behavior inconsistencies.
Introduce a new internal mode that ServiceWorker behaves like a pass through mode.
Under this mode, ServiceWorker only works with registered conditions.
For other (non-registered) conditions, ServiceWorker does not startup.
Make ServiceWorker to pass through mode if user calls event.addRoutes() once in the install event handler.
Luckily, event.addRoutes() is a newly introduced API. That method does not exist on old UAs. If user code does not call event.addRoutes(), ServiceWorker can work as a traditional style that intercept for all network requests implicitly.
For UAs that had been shipped event.addRoutes() (Google Chrome), they can just ignores some patterns of conditions to keep a backword compatibility.
The text was updated successfully, but these errors were encountered:
tetsuharuohzeki
changed the title
Can we make to avoid to invoke ServiceWorker _by default_ for if user code call **~event.addRoutes(rules)~** in install event handler?
Can we make to avoid to invoke ServiceWorker _by default_ for if user code call event.addRoutes(rules) in install event handler?
Mar 19, 2024
Motivation
event.addRoutes(rules)
was introduced by #1701 whose motivation is explained in https://github.com/WICG/service-worker-static-routing-api to reduce the overhead to intercept by ServiceWorker.According to the motivation, I seem our ideal status resolved by this API is ServiceWorker works as opt-in mode if a user code calls
event.addRoutes()
.I think almost combinations of
RouterRule
would be nice to work like opt-in semantics. However, there are some cases that are not intuitive combinations.For example, the explainer illustrates Bypassing ServiceWorker for particular resources case. This case say that ServiceWorker to behave as just as opt-out for some network request path
On the other hands, if
RouterRule.source
is"fetch-event”
or cache, ServiceWorker would work like as opt-in for registered conditions by the spec.If I don't misunderstand the spec, I think this API semantics inconsistency may confuse a developer.
Idea
I also propose a rough idea to resolve this behavior inconsistencies.
event.addRoutes()
once in theinstall
event handler.event.addRoutes()
is a newly introduced API. That method does not exist on old UAs. If user code does not callevent.addRoutes()
, ServiceWorker can work as a traditional style that intercept for all network requests implicitly.event.addRoutes()
(Google Chrome), they can just ignores some patterns of conditions to keep a backword compatibility.The text was updated successfully, but these errors were encountered: