Brief Introduction to three JS release errors that can be avoided _ basic knowledge

This article details three JavaScript release errors that can be easily avoided. If you need them, you can refer to the Web application development trend, which tends to run all user logic and interactive code on the client, expose the REST or RPC interfaces to the server. The compiler is intended for JS as a platform. The second version of ECMAScript is designed with this in mind. Client frameworks such as Backbone, Ember, and Require encourage the creation of a rich array of applications, not only with rich code, but also with a lot of interaction between various components, components and data.
This is really good. It may still produce some excellent user experience, but there is no doubt that it is difficult to develop web applications and web pages.
The root cause is to serve your code and data on the Internet and run on some random browsers. In javascript, This is a language that requires special attention, it is a platform that lacks code deployment completely. And it will not be improved soon. I think if Star Trek is a real life, the reason why Captain Jean-Luc Picard cannot fight every other time is that he is still loading the Colin dashboard.
I want to emphasize three common errors and easy solutions, and talk about some special things we have learned from ReadyForZero.
Strip the "cache cleanup" header information
It is reasonable that you may use CDN to cache static resources. If you request non-cached resources from the server (for example, using "custom-origin" on AWS to direct files to a real network site), you need to be careful. You may add a cache-cleared string (header information) to the file name after deploying a new version of the file to achieve this purpose, so that your file name looks like this:
Http://www.jb51.net/js/main__V0123456789abcdef__.js
This is easy to achieve. You can select any Hash algorithm to generate a piece of fingerprint information as this string, so that it will change with the changes in the file content. When a new url is referenced, it cannot be cached, so that it can obtain the new version on the server. The error occurs here. We recommend that you strip the "cache cleanup" header information on the network so that your server can directly provide new versions of files. If you have multiple Server clusters, the versions of different files (such as html and js) on your site may be inconsistent (for example, js has been updated but html (requested from another server) is still old). More seriously, it can easily cause the CDN to cache the wrong version. This error occurs as follows:
· In the initial stage, all servers are HTML1 and JS1.
· Server A is restarted and HTML2 and JS2.
· A client requests main _ V2 _. js from CDN. At this time, the file is new, so there is no cache on the CDN.
· CDN sends this request to the custom origin you set. It happens that this request is sent to server B.
· Server B stripped the "cache clearing" string and returned the old version.
· CDN caches old files as new ones.
This is easy to consider, but blindly following the suggestions on the Internet may lead to errors. What's worse, it seems that everything is good for you. You don't know that an error has occurred, but users in other regions may have cached the wrong version when using different CDN. Solution: Do not strip the "cache cleanup" string and store the static resources in a place that correctly supports each version.
2. Handle huge JS bombs
Everyone knows that we need to compress our javascript files and connect them together. However, it is not wise to blindly do so. If the connected file is large, a more effective method is parallelization. In addition, if you need to modify a part of a file frequently, you may cause failure in many places, but a large part of the file has not been modified.
If the frequently modified parts are separated, the problems on both sides can be solved. We recommend that you use require. js-it can implement real dependency management for your javascript, And the setting is very simple when you use it for the first time (it will be painful to add it later ), it also helps you understand and manage dependencies, including some advanced options, such as asynchronous loading.
Note: require. js will wait for a while and will discard loading resources. This can be achieved by specifying the waitSeconds option. The default value of this option seems to be 7 seconds, and it depends on where your users are (for example: mobile phone), can be a short time.
3. No summary error events
You can't just let your javascript go online without worrying about its running status. You cannot test the status combination of Each browser and each user. In addition, different loading times may lead to weird states. Therefore, it is very important to establish a feedback mechanism to determine whether your users encounter errors. This is simple. You only need to specify a global error handler to collect errors and send them to the server. The following is an example:
The tricky part is that some non-zero Errors often occur, because users may install a variety of weird plug-ins or others. So you need to track what the stable status is and whether there are any deviations.
ReadyForZero: We capture onError events on the top layer, send them to the server, and generate a daily report to summarize the number of users who have encountered errors and where these errors occurred. We found that many times the error message is not enough, so we also need to return the last few events from our event system. By analyzing the Backbone or JQuery events recently triggered by a user, it is of great help to obtain the context information when the user triggers an error at that time.
Improvements at your fingertips
It is frustrating that we do not have to worry about the following points. Companies should pay more attention to products and get them out quickly and with high quality. But remember that if these improvements are implemented, you will be able to focus more on big moves.
People are always entangled in some trivial matters and spend a lot of time, but it can only make your applications run normally to achieve great growth.
1. Is there any memory leakage in your client code? Are you sure you want? How do you know?
2. In ReadyForZero [NOTE 1], many smart people are committed to promoting this art.
[NOTE 1] ReadyForZero: A company funded by Y Combinator, the company aims to help consumers get rid of credit card debts through the network platform.