Closed dstillman closed 6 years ago
@dstillman after "hard reload" in Chrome, fetch will still take data from cache. There is a "empty cache and reload" option available but I'm not sure how many people use that (over hard reload).
Not sure whether it would be still possible to use cached data after failed fetch()
, I'll look into it.
Hmm, that's too bad re: hard reload, though maybe the only thing that makes sense from the browser's perspective. (I was sort of hoping it would use reload
the first time a given URL is requested after a hard reload.)
Re: failure, if a conditional request does indeed cause the promise to be rejected even if a cached version is available (which I suspect is the case), maybe a solution is to make a second request in the catch
with only-if-cached
?
https://developer.mozilla.org/en-US/docs/Web/API/Request/cache:
The "only-if-cached" mode can only be used if the request's mode is "same-origin". Cached redirects will be followed if the request's redirect property is "follow" and the redirects do not violate the "same-origin" mode.
We could use 'force-cache' which will use (stale) cache if available or try to do the request if not.
(Looks like only-if-cached
isn't supported anywhere other than Firefox anyway.)
Yeah, seems like force-cache
would work as the fallback. And maybe if nothing was cached the second request would succeed anyway.
Cool, that's done then.
If a style is updated, ZBib should get the style soon after, and ideally be able to get it immediately if the user does a force-reload.
Are we storing styles in local storage or using the browser cache? If the former, could we just use
fetch()
instead and rely on browser caching with conditional requests, etc.? (I'm not sure iffetch()
will do a force-reload if the user does, but I would hope so.)Also not sure about the failure state of
fetch()
— if a style is cached and a request fails — but hopefully we can set cache control headers on the repo such that a cached style is reused if available, even if possibly out of date.