Re: [whatwg/fetch] How are reloads mapped to cache modes? (#524)

>From the viewpoint of web developers, the essential question here would be how an installed SW script can handle FetchEvents of page loading in an optimized way, even for reload and history navigation. Of course, SW can work as just a http cache, but wants to do something smarter if the script can recognize navigation types.

Ideally said, if we could have a clear 1:1 map of all kinds of navigations to cache mode, it would work perfectly. But it sounds very hard because current implementation is different from each other, and is not simple. Even if everything can be spec-ed, it would become very hard to write a SW script correctly.

If FetchEvents could have a per-fetch-group navigation type that also represents UX navigations too, it would be easy to control all kinds of navigation in a simple way. Here, FetchEvent.isReload is not enough because it's also important use case to identify back/forward navigations. If the script want to work as a simple http cache, it would rely on cache mode instead of navigation type.

About spec-ing UX behaviors:
It becomes very hard for web developers to construct web sites correctly without knowing how reload or back/forward navigations work in each browser. Especially with a SW installed, it would become harder to control correctly. IMHO, this situation is not healthy for the ecosystem, and would be great if we can have a standard.

Also, in addition to UX navigations, how about JavaScript initiated navigations via Location and History interfaces?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/524#issuecomment-294780168