Detailed explanation of version management of js file cache_Basic knowledge

The work in recent months is a continuous improvement project of the trading system, with an iterative release cycle of about 2 to 3 weeks. The latest iteration is the V16 version, which was released on Wednesday. Unfortunately, he was caught by the boss the next morning. It turns out that the boss found a bug in production. The general problem is as follows:

There is a commonly used custom control in the system to assist in selecting customers, and the continuous improvement requirement for the V16 version is to add two filtering options to the control to support different default value configurations. It is a very simple requirement, and the code modification is also simple. One of the modifications is to add an incoming parameter to a function in a js file to pass configuration values. After RC and RTW testing, everything seemed normal, but the bug was discovered only after it was put into production. The loaded customers are obviously abnormal, the number is wrong, and they do not match the expected query configuration.

Check the internal jump link of the control and find a problem. The passed parameters are obviously inconsistent with expectations, and this link is generated by the JS function modified above. Therefore, it is determined that the problem is caused by the client caching the original JS file and the call of the new function being replaced by the old function. After clearing the cache and reloading the page, this custom control can work normally. Unfortunately, we can't call every user and tell them that you need to clear your cache before you can use this feature.

At this point, I realized that I needed a way to control the caching problem of JS. Otherwise, any subsequent modifications involving the content of JS files would cause production accidents because the cache cannot obtain the latest JS files.

In principle, we need to reload the JS file when there is a JS update, instead of reloading it every time. Therefore, the first approach is not advisable to add random parameters after the JS application address. Because it means that almost every time the page is loaded, the JS will be reloaded, and the cached JS will not be properly utilized. However, we have a second, more reasonable approach. If you have paid attention to some foreign website codes, you will find that they usually add a version number parameter after the js link instead of a random number. When the js code is modified At this time, you only need to add 1 to the version number, and you can cleverly solve the problem of notifying the client to update the js file. I don’t know who was the first person to think of this method, but there is no doubt that he deserves our admiration. It’s really a good idea!

Comes with some code: