Closed trusktr closed 11 months ago
I think the queryForAllRequests
not that meaningful. Maybe we could have some config like
window.$docsify = {
alwaysFetchLatest: true
}
Then docsify gonna add something like UUID or random version string, timestamp... on the query.
About the Requests
, we make could expose a hook for user to custom Requests
before we do fetch.
@Koooooo-7 Interesting idea! There is one issue with alwaysFetchLatest: true
: we don't necessarily want users of a website to always fetch the latest every time, because that will disable the benefits of browser caching and every access to a website will always be fetching from a server (higher monetary cost if someone has a website with lots of traffic).
Ideally want a website's users to fetch new content after we've updated the website.
I think the alwaysFetchLatest
idea could be useful, but perhaps not for everyone.
The idea with queryForAllRequests: 'abc'
is that we can update it when we want to specifically bust the cache for an update.
Maybe a better alternative for queryForAllRequests: 'abc'
would be siteVersion: 123
: when someone makes an update, they can change the number manually, or they can add tooling that places package.json version value there, etc.
This may also relate to
I think the
queryForAllRequests
not that meaningful. Maybe we could have some config likewindow.$docsify = { alwaysFetchLatest: true }
Then docsify gonna add something like UUID or random version string, timestamp... on the query.
About the
Requests
, we make could expose a hook for user to customRequests
before we do fetch.
window.$docsify = {
...
requestHeaders: { 'cache-control': 'no-cache', },
...
};
This code snippet sets the "cache-control" request header to "no-cache". This means that the client (e.g., a web browser) will not use any cached responses when making this request, and instead it will always send a fresh request to the server.
In other words, it ensures that the latest version of a resource is fetched from the server each time the request is made, rather than using a possibly outdated copy from the cache.
After testing, it was found that this code only takes effect on .md
files, while other file types such as js
, css
, or png
are not affected. This should meet your requirements.
@sogadm's suggest is good for those who with to address cacheing issue via a configuration option. The danger with this method is that site owners may use this option during testing, forget to remove it when done testing, and end up with a live site that disables cacheing for all visitors.
Another option is to disable cacheing using your browser's developer tools. This removes the risk of forgetting to remove any kid of test-related cache options.
For example, add a new
queryForAllRequests
option that is used for all requests. This specifies a query string to use in every request, and when someone updates their site, they can update this string, which will force a browser to treat all requests as new files from network instead of from cache.where any time we update our website, we can change this value, which will force the browser to see all files as new files (uncached). We could then set the cache lifetime to larger number, and use only this approach to bust the browser cache. For example, the browser would request
https://example.com/path/to/file.md?id=123
instead of justhttps://example.com/path/to/file.md
. When we update our site, we can change the option to'id=124'
for example, and then the browser will fetchhttps://example.com/path/to/file.md?id=124
which it will see as a new file and will fetch it from network instead of from local cache.