JS's modular process
Now the front-end technology is changing rapidly, for the same problem pain point, each time has its own solution, which brings a great difference. Today, I'm going to comb the history of JS Modularity, and talk about what these programs do and how to do them.
The cause of the JS modular process
Many of today's web pages can actually be seen as feature-rich applications that have complex JavaScript code and a whole bunch of dependent packages. When the development of a project becomes more and more complex, you will encounter some problems: naming conflicts (variables and function names may be the same), file dependencies (introduction of external file numbers, order problems), etc.
JavaScript is growing faster than it is when it comes to self-positioning. At this time, JS Modularity appears.
What is modular
Modular development is a kind of management mode, is a mode of production, a solution to the problem. He follows a function to cut a piece of software into many parts and then assemble it, each of which is a module. When using modular development, you can avoid just the problem, and make development more efficient, and convenient for later maintenance.
JS Modular Process One, early: script tag
This is the most primitive way to load JavaScript files, if each file is considered a module, then their interface is usually exposed to the global scope, that is, defined in the Window object.
Disadvantages:
1. Contamination global scope
2. Can only be loaded in the script label writing order
3. Document dependencies are subject to the developer's subjective resolution
Ii. Development One: COMMONJS specification
Allows the module to synchronously load (synchronously means blocking) other modules through the Require method, and then exports the interfaces that need to be exposed through module.exports.
// Module Add.js function return A + b;} // Main.js var {Add} = Require ('./math '); Console.log (' 1 + 2 = ' + add ');
CommonJS is a project designed to build a JavaScript ecosystem outside of a browser environment , such as in a server and desktop environment.
Iii. Development II: Amd/cmd (1) AMD
AMD is the normalized output (definition of asynchronous modules) that REQUIREJS defines for modules during the promotion process.
The following two APIs are defined in the AMD standard:
- Require ([module], callback);
- Define (ID, [depends], callback);
The Require interface is used to load a series of modules, and the Define interface is used to define and expose a module.
function (A, b) { // dependencies must be written in the first a.add1 () ... B.ADD2 () ...
Advantages:
1, suitable for loading modules asynchronously in the browser environment 2, can load multiple modules in parallel
(2) CMD
CMD is the normalized output of the module defined by SEAJS in the process of generalization. (presented on the basis of COMMOMJS and AMD)
Define (function (Requie, exports, module) { // var a = require (' ./a '); A.ADD1 (); ... if (status) { var b = Requie ('./b '); B.ADD2 ();
Advantages:
1, rely on the nearest, deferred execution 2, can be easily run in the server
(3) The difference between AMD and CMD
AMD and CMD are very similar, but there are some subtle differences:
1, for the dependent module, AMD is implemented in advance, CMD is deferred execution.
2, AMD respected the reliance on the front, CMD respected rely on the nearest, only when the use of a module to require.
3, AMD's API default is a when multiple use, CMD API strictly differentiated, advocating the role of a single
Iv. Development III: ES6 Modular
The ECMASCRIPT6 standard adds a modular system definition to the JavaScript language level.
In ES6, we export the module using the Export keyword and use the Import keyword to refer to the module.
// Module MATH.JSX default class Math extends react.component{} // main.jsimport Math from "./math";
At present, few JS engines can directly support the ES6 standard, so the Babel approach is actually to translate the unsupported import into the currently supported require.
JS Modular Process