On JavaScript-modularization specification

One, JS modular evolution of the process

1. General function Encapsulation

1 function fn1 () {23} 4 5 function fn2 () {67 }

The initial disadvantages of this common function seal are obvious: pollution of the global variables, can not be avoided and other modules have a variable name conflict, and there is no connection between the members of their own modules, that is not done "high cohesion, low coupling" the original

2. Objects

1 var mymodule =   2     var1:1,  3     var2:2,  4     function () {  5  6    },  7     function () {  8  9    }

Technology has been improving, this approach to avoid the variable pollution, as long as the only guarantee module name, the members of their own modules have also been linked;

But new problems emerge, seemingly good solutions, there are flaws, external can be arbitrarily modified internal members;

such as: Mymodel.val = 100; Frankly, it's a security issue.

3. Execute functions immediately

1 varMyModule = (function(){ 2     varVAR1 = 1;3     varVAR2 = 2;4     functionfn1 () {5 6     }7     functionfn2 () {8 9     }Ten     return {  One fn1:fn1, Fn2:fn2 A     }; -})();

This approach is the basis of our JS modular, technology is endless, with the JS modular technology to improve, has produced different schools, branches; there are two main types: Commonjs and AMD

Two, CommonJS

1. Define the module:

According to the COMMONJS specification, a single file is a module, and each module is a separate scope, that is, a variable defined inside its own module that cannot be read by other modules unless it is defined as a property of a global object

2. Module output:

Each module has only one exit, that is, the Module.exports object, and we need to put the content that the module wants to output into the object

3. Load the module:

The load module uses the Require method, which reads a file and executes it, returning the Module.exports object inside the file

1 //module Definition2 Mymodel.js3 varname = ' Byron ';4 functionPrintname () {5 Console.log (name);6 }7 functionPrintfullname (firstName) {8Console.log (FirstName +name);9 }TenModule.exports = {  One Printname:printname, A Printfullname:printfullname - } - //Loading Modules the varNamemodule = require ('./mymodel.js ')); -Namemodule.printname ();

different implementations of the require when the path has different requirements, the general situation can omit the JS extension name, you can use the relative path, you can use the absolute path, or even omit the path directly to use the module name (if the module is a system built-in module)  

Problem:

Looking closely at the code above, you will find that the require is synchronous. The module system needs to read the module file contents synchronously and compile execution to get the module interface.

This is simple and natural to implement on the server side, however, there are a lot of problems to be implemented on the browser side.

On the browser side, the best and easiest way to load JavaScript is to insert a script tag in the document. But script tags are inherently asynchronous, and traditional COMMONJS modules do not load properly in a browser environment.

One of the solutions is to develop a server-side component that makes static analysis of the module code and returns the module to the browser side, along with its dependency list. This works well, but requires the server to install additional components and therefore adjusts a series of underlying architectures.

Another solution is to encapsulate the module definition with a set of standard templates, but for how the module should be defined and loaded, the resulting

Third, AMD

AMD is the asynchronous module definition, the Chinese name is the meaning of the asynchronous module definition. It is a specification for modular development on the browser side.

Because it is not JavaScript native support, the use of the AMD Specification for page development requires corresponding library functions, known as REQUIREJS, in fact, AMD is requirejs in the promotion process of the module definition of the normalized output.

Requirejs mainly solves two problems

1. Multiple JS files may have dependencies, the dependent files need to be loaded into the browser earlier than the files that depend on it

2.js load when the browser will stop the page rendering, the more loaded files, the longer the page lost response time

Grammar

Requirejs defines a function define, which is a global variable used to define the module.

Define (ID?, dependencies, Factory);

ID: Optional parameter to define the identity of the module, if not provided, the script file name (remove extension);

Dependencies: is an array of module names that are dependent on the current module

Factory: Factory method, module initializes the function or object to execute. If it is a function, it should only be executed once. If it is an object, this object should be the output value of the module;

1 //Defining Modules2 Mymodule.js3define ([' dependency '),function(){ 4     varname = ' XLW ';5     functionPrintname () {6 Console.log (name);7     }8     return {9 Printname:printnameTen     }; One }); A //Loading Modules -Require ([' MyModule '),function(my) { - my.printname (); the});

Loading modules on the page using the Require function

1 function () {2     3 });

The Require () function accepts two parameters

The first parameter is an array that represents the module on which it is dependent

The second parameter is a callback function that will be called when the module specified by the current polygon is loaded successfully. The loaded module passes in the function as a parameter, allowing the modules to be used inside the callback function

The Require () function is loaded asynchronously when the dependent function is loaded, so that the browser does not lose its response, it specifies the callback function, and only the previous modules are loaded successfully, which solves the dependency problem.

Please leave a message to add

(End ~ ~)

On JavaScript-modularization specification