Three specifications for front-end modularization

This time I will bring you three specifications of front-end modularization. What are the precautions of front-end modularization specifications? Here are practical cases, let’s take a look.

Speaking of modularity, it is undeniable that this has become a consensus in front-end development, and I have gradually accepted the concept of modularity during development, and deeply realized the benefits of modular development. Why do you say that? Let’s look at a simple piece of code: (without modularization)

This is a phenomenon that can often be seen before modularization is used: putting a bunch of js in At the bottom of the body, but did you know? There are two big problems with this approach:

1. The order of root.js, tree.js, and leaf.js from top to bottom cannot be messed up. , because leaf depends on tree, and tree depends on root, it will not work if the order is changed;

　2. If I am a novice or a successor, when I get leaf.js, I know that it depends on tree.js, but do I know that tree.js actually depends on root.js? Maybe root.js needs to rely on other js to run?

　Modularization appeared at this time, precisely to save the uncertain dependencies between js files.

　　AMD specification

Speaking of this specification, people who use it now It is already very rare. The cornerstone of this specification is that you must first introduce a require.js in the html file, just like if you use the syntax of jQuery, you must first introduce it. jQuery.js is loaded in the same way. After introducing this annoying require.js, a bunch of js files are divided into three categories:

The first category: simple define(), because In require.js, the reference to the resource (that is, the resource is passed in as a parameter) must be defined first, and then require/define. This type is responsible for pure definition;

The second category: define(["other defined js"]) with parameters. In this category, other defined js are referenced, and at the same time, you define another thing yourself, which is a double responsibility. Responsibility;

The third category: simple require(["Other defined js1", "Other defined js2",... ]), in this category, you only need to focus on citing resources, and you can quote many resources.

How about it? Do you feel it is troublesome? It is necessary to globallydefine the function, and what require.js should be referenced, abandon it angrily.

　CMD specification

In fact, there is no essential difference between CMD and AMD specifications. The difference lies in their different processing of execution timing of dependent modules. Although both load modules asynchronously, AMD relies on front-end, js can easily know who the dependent module is, and what js you need to depend on, load it first. As for why you want to rely on these js, you have to wait first. We will discuss it after I finish loading the resources; CMD is a nearby dependency, and when I need to use this dependent module, I will load it in and use it.

　What is this like? It’s like I’m going to watch 5 episodes of Romance of the Three Kingdoms tonight. AMD opens five windows first, which are episodes 1 to 5, and buffers them all first. Anyway, I will watch each episode later; CMD opens the window of the first episode first, and waits until I finish watching the first episode. If you want to watch the second episode, just jump to the second episode.

　CommonJS Specification

In general, the above Neither of them is my cup of tea. The one that is most frequently used now and is recognized by everyone as a good modular specification is CommonJS.

CommonJS is very simple. To export a js file, just use module.export={xxx: the content you want to output}, and in another js, what do you want to quote? , just reference it through var xxxx=require("xxxx"). This thing is not loading the module asynchronously, but loading it synchronously in one go. Personally, I feel that this standard can be said to be somewhat good, and even using "666" to describe it is not false at all. I recommend everyone to use this standard.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!

Recommended reading:

Vue.js form input binding

##What are the rules for converting JS type values ​​into Boolean types

The above is the detailed content of Three specifications for front-end modularization. For more information, please follow other related articles on the PHP Chinese website!