In-depth analysis of JavaScript refactoring (1)

Usually, in our team, developers have considerable technical literacy and experience at the Java language level, and there are many mature and reasonable conventions and a wide variety of code risk check tools, there are even planned reviews and flight inspections among teams. However, the front-end code is not like the back-end code. It is like a child who has no one to hurt. It is not only easy to be underestimated, but also despised, resulting in poor quality, poor maintainability, and skill, lack of excellent front-end developers.

JavaScript is an important part of the front-end code. As the version continues, the product grows and the JavaScript reconstruction needs to be gradually strengthened throughout the process.

When the amount of code reaches a certain level, JavaScript should be modularized with page module components (such as custom FreeMarker labels.

The biggest benefit of modularity is independence and maintainability. You do not need to locate the problem in a large number of JavaScript files. This is easy to understand and accept, and easy to customize.

It is best to keep the dependency between modules simple, for example, there is a common. javaScript code is the most common function-type code that does not contain or contain globally managed variables. Therefore, it must be released independently. Other js components can be easily dependent on it. For example, we often need to implement a trim method for the string, but js itself is not available, so we can use this common. extension string prototype in js to achieve this, which is transparent to external users.

Module division and namespace

Namespace is a good way to keep js from interfering with each other. js must follow the principles of encapsulation, inheritance, and polymorphism when focusing on object orientation.

With reference to the usage of Java import, I hope the namespace can bring this effect. Let's look at the simplest example:

I have a module play, which contains a webOnlinePlay method. If this module is not imported, I expect that js execution is incorrect:

 
 

  
  
WebOnlinePlay ();// Error! The method cannot be found. 
 
 

However, if I introduce this module:

 
 

  
  
Import("Play");
  
  
WebOnlinePlay ();// Correct. The method can be found. 
 
 

In fact, the implementation of this effect is also very simple, because the essence of the webOnlinePlay () method called by default is: window. webOnlinePlay (), right?

Therefore, during import ("play"), the internal implementation mechanism is as follows:

 
 

  
  
var module = new playModule(); 
 
 

Every method in this module is imported to the window object to directly use:

 
 

  
  
window[methodName] = module[methodName]; 
 
 

In fact, there is no xuanjicang here, but such an out-of-the-box thinking has brought a new idea to front-end refactoring. Isn't it the idea of enhanced maintainability brought about by encapsulation?

You may also raise the following question:

If I have not imported this play module and this page is not required, can I not even load this play. js?

Of course you can. Pay attention to the next page-about the dynamic loading of js.