1. Demand analysis

Often when a front-end project goes live after iteration requirements or temporary bug fixes, we expect the client to quickly check that the project has been updated and refresh the page. There are many testing items and new methods. Here I provide a simple method with high applicability.

2. Code examples and analysis

First directly paste the source:

Let previousTimeTag (async Function () {// Record the timestamp of the first request by executing the function immediately, PreviousTimeTag = await getTimeTag() window.versionMonitor&&clearInterval(window.versionMonitor) // VersionMonitor = setInterval(() => {judge()}, 60 * 1000) }()) async function getTimeTag () { const response = await fetch(`${window.location.protocol}//${window.location.host}`, { method: 'HEAD', cache: 'no - cache'}) / / for the etag response body or last-modified timestamp return response. The headers. Get (' etag ') | | Response.headers. Get ('last-modified')} Async function judge () {// Get the latest timestamp const currentTimeTag = await GetTimeTag () if (previousTimeTag! == currentTimeTag) {// write the update logic here}}Copy the code

The logic is very simple: when logging the first request, negotiate the eTAG or last-modified previousTimeTag in the cache as the first timestamp, and then poll the same address for the latest timestamp currentTimeTag. If the previousTimeTag and currentTimeTag are inconsistent, the refresh prompt logic is executed. The flowchart is as follows:

Bug: If the server disables negotiation caching, there is no way to use this method.

3. Code detail analysis

1. The etag and last-modified

Both are fields in the response header that record information about the negotiation cache.

An ETAG is a token associated with a Web resource. It can be understood as a hash code generated by the content of the Web resource. If the contents of the two Web resources are inconsistent, the generated ETags are also inconsistent. Fields belonging to HTTP1.1.

Last-modified Records the time when the Web resource was last modified. Fields belonging to HTTP1.0.

Cite an online article to explain why ETAG has a higher priority than last-modified

Etag is designed to solve some problems that last-Modified cannot:

1. Some files may be changed periodically, but the contents of the file are not changed (only the modification time is changed). At this time, we do not want the client to think that the file has been changed and GET again.

2. For files that are Modified very frequently, such as in seconds or less (say N changes in 1s), the granularity that if-modified-since can be checked is s, which is impossible to determine (or the UNIX record MTIME can only be accurate to seconds).

3, some servers can not accurately get the last modification time of the file;

2.HEAD request method

HEAD is essentially the same as GET. The difference is that HEAD contains only the corresponding line in the corresponding line and the response header, not the response body. Usually used to check whether a file exists on the server. Because there is no response body, the corresponding volume is smaller and the response time is shorter.

3. Cache Settings in fetch

Default: Shared negotiation cache and strong cache

  • If the cache matches and is fresh, it returns the resource directly from the cache.
  • If the cache matches but has expired, the browser will use traditional conditional request to access the remote server. If the server side shows that the resource has not changed, it returns the resource from the cache. Otherwise, if the server displays resource changes, the resource is re-downloaded from the server to update the cache.
  • If the cache does not match, the browser will request it in the normal way and update the cache of the resource that has been downloaded.

No-store: The browser obtains resources directly from the remote server, does not view the cache, and does not update the cache with the downloaded resources.

Reload: The browser gets the resource directly from the remote server, without looking at the cache, and then updates the cache with the downloaded resource.

No-cache: The browser looks for a matching request in its HTTP cache.

  • If there is a match, either new or old, the browser makes a conditional request to the remote server. If the server indicates that the resource has not changed, the resource is returned from the cache. Otherwise, resources are downloaded from the server and the cache is updated.
  • If there is no match, the browser makes a normal request and updates the cache with the downloaded resource.

More details can be found in the MDN documentation: developer.mozilla.org/zh-CN/docs/…