Re: [w3c/ServiceWorker] Can we make to avoid to invoke ServiceWorker _by default_ for if user code call `event.addRoutes(rules)` in `install` event handler? (Issue #1712)

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1712)

You can find sites using the ServiceWorker static routing API in https://chromestatus.com/metrics/feature/timeline/popularity/4711.
I feel most of them are using a library that uses the API behind.  However, as far as I picked sites listed, I failed to find sites that is trying to skip a fetch handler completely with the API.

I expected rules like followings in the end.
```
{
    condition: {
      urlPattern: new URLPattern()
    },
    source: "network"
}
```
or
```
{
    condition: {
      or: [ {requestMethod: "get"},
        {not: {requestMethod: "get"}}
      ]
    },
    source: "network"
}
```

They seem to try to avoid using fetch handler for specific resources, though.

> > If you want to completely skip the fetch handler, you can explicitly add a rule to catch all to go to "network" before the default route.
> 
> My intention of this proposal is that a developer can skip to write such thing.

Can I ask why avoiding writing code like above is important?
Do you have a specific request from your users, are there statistics, or anything else?

> I think we have a optimization chance and I guess this not might cause a destructive behavior change.

There are sites using the API already.  The proposal should bring behavior change on their API usage.

> First, I think that we can regard as that calling `InstallEvent.addRoutes()` is an developer’s sign for optimization for an user agent. On a user agenet that does not support it, an user application will not call it. It would not a violate an exist code even if `InstallEvent.addRoutes()` introduce a new internal concept that allows some optimizations. And this assmption would not be against to the original motivation of [#1701](https://github.com/w3c/ServiceWorker/pull/1701), I think.

As far as I saw the existing usage, I feel the developers try to use a fetch handler for a specific resource, but they seem to want a fetch handler for others.

> Second, an application can call `InstallEvent.addRoutes()` only in `install` event handler. `fetch` event would a wait to complete `install`. There are lifecycle order. If an application did call `InstallEvent.addRoutes()`, user agent can fire`fetch` event under this proposal’s assumption. On the contrary, if an application does not call `InstallEvent.addRoutes()`, user agent should fire `fetch` event with the traditional manner.

I am sorry, I failed to catch the point.  The install event must happen before the fetch event, and regardless of `addRoutes()` is called or not, the fetch event will come (or may not come) after.
Will you rephrase this?

Also, the install event happen once after the registration until an update.  I think the event rarely happen, and we may not need to focus on its performance.

> Third, I think this proposal can reduce a application code with the achievement of static routing API’s motivation.

Again, can I ask why reducing the application code is so important?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1712#issuecomment-2664987409
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1712/2664987409@github.com>