Shulou(Shulou.com)06/03 Report--

This article shares with you the content of the sample analysis of module in js. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

JS itself is a versatile language, a language with a high degree of freedom to compile on its own. Because of this freedom, there are hype norms and frameworks, the most basic of which is Module.

Come on, baby, let's take a little test: CommonJS ·AMD ·CMD ·UMD ·ES6. How many of these module specifications are you familiar with?

Note: this article is the cheerful offline cognition written by the author subjectively, which may be different from the history of the formation of the real module.

The root of everything

JS is a language with a high degree of freedom, even without the concept of modules. You can also implement concepts similar to modules by IIFE,new an object. It can also be reusable, scope independent and easy to maintain. In this way, it is impossible to maintain the dependence between the various modules. In a JS file, if there are more than one module, it may be a meditation field.

The birth of Module

So JS Module, a noun that people love and hate, was born. JS itself does not have the concept of module, and then in order to make JS into a powerful language, industry leaders show their talents, set a specification called CommonJS, and implement a thing called module. Unfortunately, most browsers do not support it and can only be used for nodejs, so CommonJS began to split and mutated a module called AMD specification, which can be used on the browser side. Because AMD is so different from the CommonJS specification, AMD has its own door and launched the framework requireJS to implement and promote the AMD specification. Because AMD and CommonJS are so different and used in different environments, in order to be compatible with the two platforms, UMD arises at the historic moment, but the author thinks that it is only one polyfill to be compatible with the two platforms. At this point, proponents of CommonJS believe that browsers can also implement the CommonJS specification, so with a slight change, the CMD specification is formed, and the framework seajs is introduced. While AMD was in love with CMD, ECMAScript6 set a module loading function for JS itself, and ES6 said, "Don't argue, the JS module has a native syntax."

The real norm

Among the many specifications, only CommonJS and ES6 import/export are the real specifications, and the rest are simulated environments using the existing methods supported by JS to implement their respective specifications.

As for why CommonJS and ES6 import/export are the real specifications? Because their specifications can be implemented only if they are natively supported by their syntax.

For CommonJS, the running environment must have the support of require and module.exports in order to run. This is the main reason why browsers are out of touch with CommonJS.

As for ES6, without support for the import and export keywords, everything is zero. For example, nodejs does not support import and export. Obviously, nodejs supports other ES6 grammars, so why are they so unfriendly to import and export? the author believes that nodejs is to implement the specification of commonJS, so it can not accept the module of ES6 to disturb the module specification of nodejs.

So the modules of CommonJS and ES6 are the real specification.

With regard to CommonJS and ES6 modules, I have written an article about them. Without going into detail here, I will move on to module loading that understands CommonJS.

The principle of implementing CommonJS Module by browser

Since the browser lacks two keywords of CommonJS, the module is not set up, so create a module environment. Using the define method, the interior of the function is simulated into the environment of CommonJS, and the methods of require and module.export are provided. Both seajs and requirejs realize module by means of define simulation environment.

AMD who set up his own door

The author was in the DIY desktop, when choosing a graphics card, hesitated between A card and N card, and then decisively chose A card, because A card is cheaper. The A card here refers to AMD, so does it have anything to do with the AMD of JS here? It doesn't matter! It's just a beautiful coincidence that the acronym AMD of JS module is the same as the name of AMD company in the United States.

The full name of AMD is Asynchronous Module Definition, and the Chinese name is the definition of asynchronous module, which is different from the demand loading of CommonJS, that is, after require is added, AMD loads and runs all the packages that are potentially needed, that is, the legendary high configuration, as to whether it can be used is no longer within the consideration of AMD. Requirejs is representative of AMD:

Critical strike from AMD:

Define ("module1", function (require) {'use strict'; console.log ("cccc")}); define ("module2", function (require) {' use strict'; console.log ("aaaa") if (false) {console.log (require ("module1")} console.log ("bbbb")}); require (["module2"])

Printing cccc,aaaa,bbbb at this time, it can be seen that AMD will be all the modules, before the module execution, all loaded, so there is another way to write AMD is to write all dependent modules to the header.

Define ("module1", function (require) {'use strict'; console.log ("cccc")}); define ("module2", [module1], function (module1) {' use strict'; console.log ("aaaa") if (false) {console.log (require ("module1"))} console.log ("bbbb")})

Take a look at the requirejs source code:

Requirejs has two ways to acquire dependencies, one is to configure, and the other is to use rules to match all the contents of require, and then add dependencies. When calling the current module, check to see if the dependent module is running.

CjsRequireRegExp = / [^.]\ s*require\ s *\ (\ s * ['] ([^'"\ s] +) ["']\ s *\) / g

The defined module is cached in an object with the name of the module as the only health value, and then if the cached module is called again, it does not need to be executed again.

Cache the results after execution

Defined [id] = exports

The second execution, first check whether it already exists, if so, why not repeat the execution.

Function callGetModule (args) {/ / Skip modules already defined. If (! hasProp (defined, args [0])) {getModule (makeModuleMap (args [0], null, true)) .init (args [1], args [2]);}

If it is a remote dependency, create a script, load the remote resource, and add script to the header.

Req.createNode = function (config, moduleName, url) {var node = config.xhtml? Document.createElementNS ('http://www.w3.org/1999/xhtml',' html:script'): document.createElement ('script'); node.type = config.scriptType | |' text/javascript'; node.charset = 'utf-8'; node.async = true; return node;}

So what kind of existence is UMD?

The first time I came into contact with UMD was in the packaging of webpack. If you want to generate a library, there are many options, CommonJS,amd,umd. I was a little confused at that time. What is UMD? Without knowing it, there is another module specification, which makes the author's head very big.

Gaze from webpack:

Output: {path: path.join (_ _ dirname), filename: 'index.js', libraryTarget: "umd", / / here is the type of plug-in you want to package: library: "Swiper",}

Take a look at the effect of the package:

! function (root,callback) {"object" = = typeof exports&& "object" = = typeof module?// determines whether it is a nodejs environment module.exports=callback (require ("react"), require ("prop-types")): "function" = = typeof define&&define.amd?// determines whether it is requirejs's AMD environment define ("Swiper", ["react", "prop-types"], callback): "object" = = typeof exports?// is equivalent to connecting to module.exports.Swiper exports.Swiper=callback (require ("react") Require ("prop-types"): root.Swiper=callback (root.React,root.PropTypes) / / Global variable} (window,callback)

Such a polyfill is instantly compatible with CommonJS,AMD and a global module. This is UMD, and rather than a specification, it is a compatible polyfill that supports multiple module specifications.

Where is CMD?

Sharp-eyed friends should have noticed that CMD is missing and there is no option for the CMD module in webpack packaging. CMD is actually based on the CommonJS specification and then modified to support a specification on the browser side.

Let's focus on the main differences between him and AMD:

The require keyword introduces the order in which the content is executed. AMD is a concept that relies on pre-loading, while CMD executes synchronously, executing a current module after encountering a require.

Define ("c", function (require, exports, module) {console.log ("bbb")}); define ("b", function (require, exports, module) {console.log ("aaa") require ("c") console.log ("ccc")}); seajs.use ("b")

In this way, aaa,bbb,ccc is printed. Execute in the order in which the code appears.

Of course, this is the difference between synchronous code. As for asynchronous code, both CMD and AMD are loaded into head through script,append, stored in module objects, and then called according to id. CMD is a little different, however, with a small optimization:

If (! data.debug) {head.removeChild (node)}

When the code is loaded and cached in the module, the script is deleted in head.

Postscript

To borrow a phrase from Lu Xun, "there is no road in the world, but if there are many people walking, it will become a road." The same is true of the JS MODUDLE specification, where more people are used, which is the default solution.

This is the end of the JS MODULE war. No one knows how long the specifications of these modules will survive, but the concepts are good. So learn the concept well, even if there are new norms, compare with the old norms, find out the differences and analyze them, you will be able to get started easily!

Reference address

Don't forget the articles that help the author to recognize the module. Thank you, bosses:

Requirejs:requirejs 's website produces a historical interpretation of AMD.

The history of front-end modular development: the views of the bosses of seajs on modules sort out the author's confusion about AMD.

An explanation of AMD and requirejs on overflow

Thank you for reading! This is the end of this article on "sample Analysis of module in js". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.