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

This article will explain in detail how to understand the modularization in JavaScript advanced grammar. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

What is modularization?

What exactly is modular, modular development?

In fact, the ultimate goal of modular development is to divide the program into small structures.

This structure to write their own logic code, has its own scope, will not affect other structures.

This structure can export the variables, functions, objects, etc. that you want to expose to its structure for use.

You can also import variables, functions, objects, etc., from another structure in some way.

The structure mentioned above is the module, and the process of dividing the development program according to this structure is the process of modular development.

The history of modularization

In the early days of web development, Brendan Eich developed JavaScript only as a scripting language, doing some simple form validation or animation implementation, etc., at that time there was very little code:

At this point, all we need to do is talk about the JavaScript code that writes

There is no need to write in multiple files.

But with the rapid development of front-end and JavaScript, JavaScript code becomes more and more complex:

The emergence of ajax and the separation of front-end and front-end development means that after the back-end returns data, we need to render the front-end page through JavaScript.

With the advent of SPA, front-end pages become more complex: a series of complex requirements, including front-end routing, state management, and so on, need to be implemented through JavaScript.

Including the implementation of Node, JavaScript to write complex back-end programs, no modularization is a fatal sore.

Therefore, modularization has been a very urgent need for JavaScript. That's why ES6 (2015) launched its own modularization scheme.

Before that, in order to make JavaScript support modularization, many different modularization specifications emerged: AMD, CMD, CommonJS, and so on.

There are no problems caused by modularization

Such as naming conflicts.

Solve the above problem by immediately calling the expression (IIFE). Because the function has its own scope, it will not cause different file naming conflicts.

/ a.js var moduleA = (function () {var name = "llm" var age = 22 var isFlag = true return {name: name, isFlag: isFlag}}) () / / b.js var moduleB = (function () {var name = "zh" var isFlag = false return {name: name IsFlag: isFlag}}) () / / use moduleA.name moduleB.name

However, we actually bring about new problems:

I have to remember the name of the object returned in each module in order to use it correctly in other modules.

The code is written in such a mess that the code in each file needs to be wrapped in an anonymous function.

In the absence of appropriate specifications, everyone and every company may be arbitrarily named, or even the same module name.

Therefore, we will find that although modular, but our implementation is too simple, and there is no specification.

We need to develop a certain specification to restrict everyone to write modular code according to this specification. This specification should include core functions: the module itself can export exposed properties, and the module can import the attributes it needs. In order to solve the above problems, a series of useful specifications have emerged in the JavaScript community, and then we will learn some representative specifications.

CommonJS specification and Node

We need to know that CommonJS is a specification, which was originally proposed to be used outside the browser, and was named ServerJS at that time, and later changed to CommonJS in order to reflect its universality, which is usually referred to as CJS.

Node is a representative implementation of CommonJS on the server side.

Browserify is an implementation of CommonJS in browsers.

The webpack packaging tool has support and transformation for CommonJS.

Therefore, CommonJS is supported and implemented in Node, so that we can easily carry out modular development in the process of developing node.

Each js file in Node is a separate module.

This module includes the core variables of the CommonJS specification: exports, module.exports, require.

We can use these variables to facilitate modular development.

As we mentioned earlier, the core of modularization is export and import, which is implemented in Node:

Exports and module.exports can be responsible for exporting the content in the module.

The require function can help us import content from other modules (custom module, system module, third-party library module).

Node.js modularization

CommonJS is supported and implemented in Node, so that we can easily carry out modular development in the process of developing node:

Each js file in Node is a separate module.

This module includes the core variables of the CommonJS specification: exports, module.exports, require.

Exports and module.exports can be responsible for exporting the content in the module.

The require function can help us import content from other modules (custom module, system module, third-party library module).

We will introduce the use of exports, module.exports, and require in the future.

Exports is an object, we can add many attributes to this object, and the added attributes will be exported.

We can also export an object directly through module.exports.

We import a file through the require () function. And the variables exported by the file.

Let's introduce a module.exports in detail.

There is no concept of module.exports in CommonJS.

But in order to export modules, Node uses Module classes, and each module is an instance of Module, that is, module.

So what is really used for export in Node is not exports at all, but module.exports.

Because module is the real implementer of the export.

And assign exports to module.exports internally.

The import and export of this way has the following characteristics:

The files in Node run in a single function. You can verify this by printing console.log (arguments.callee + "").

The import and export is a reference to the value, and if you export a basic data type value, the export file changes the value, and then the import file does not change the value of the variable.

/ / a.js const obj = require (". / b.js") console.log (obj) setTimeout (() = > {obj.name = "llm"}, 1000) / / b.js const info = {name: "zh", age: 22 Foo: function () {console.log ("foo function ~")}} setTimeout (() = > {console.log (info.name) / / llm}, 2000) module.exports = info

It is imported through the require function, and the module dependencies are known only when the js code is executed.

The code is executed synchronously.

The module is introduced many times and is loaded only once. There is a loaded inside each module to determine if it has been loaded.

When the code loop is introduced, depth takes priority to load the module. And then breadth first.

Let's introduce the import details of a require in detail.

We now know that require is a function that helps us bring in an exported object in a file (module).

So, what are the search rules for require?

For more information on finding rules, please visit here

Here I summarize the common search rules: the import format is as follows: require (X)

Loading details of the module

When the module is introduced for the first time, the js code in the module is run once

When the module is introduced multiple times, it will be cached and eventually loaded (run) only once

Why is it only loaded and run once?

This is because each module object module has one property: loaded. For false indicates that it has not been loaded, and for true that it has been loaded.

If a loop is introduced, what is the loading order?

As shown in the figure above, Node uses a depth-first algorithm: main-> aaa-> ccc-> ddd-> eee-> bbb

Shortcomings of CommonJS specification

The CommonJS load module is synchronized:

Synchronous means that the contents of the current module can not be run until the corresponding module is loaded.

This will not be a problem on the server, because the js files loaded by the server are local files, and the loading speed is very fast.

What if you apply it to the browser?

The browser needs to download the js file from the server before loading and running it.

Then using synchronization means that subsequent js code will not work properly, even if it is a simple DOM operation. So in browsers, we don't usually use the CommonJS specification. Of course, using CommonJS in webpack is another matter. Because it turns our code into code that the browser can execute directly.

AMD specification

In the early days, AMD or CMD was usually used in order to use modularity in browsers. But at present, on the one hand, modern browsers already support ES Modules, on the other hand, with the help of webpack and other tools, we can realize the conversion of CommonJS or ES Module code. AMD and CMD have been used very little, so let's do a simple drill here.

AMD is a modular specification mainly applied to browsers:

AMD is an abbreviation for Asynchronous Module Definition (Asynchronous Module definition). It uses asynchronous loading module.

As we mentioned, the specification only defines how the code should be written, and only with a specific implementation can it be applied.

The more common libraries implemented by AMD are require.js and curl.js.

The use of require.js

The script tag that defines the HTML is introduced into the require.js and defines the entry file. The function of the data-main property is to load and execute the file of src after it has been loaded

/ / index.html / / main.js require.config ({baseUrl:', / / default is the folder path of main.js paths: {foo: ". / foo"}}) require (["foo"], function (foo) {console.log ("main:") Foo)}) / / foo.js define (function () {const name = "zh" const age = 22 function sum (num1, num2) {return num1 + num2} return {name, age, sum}}) CMD specification

The CMD specification is also a modular specification applied to browsers:

CMD is an abbreviation for Common Module Definition (Universal Module definition). It also uses an asynchronous loading module, but it absorbs the advantages of CommonJS.

The more common library implemented by AMD is SeaJS.

The use of SeaJS

Introduce sea.js and use the main entry file.

/ / index.html seajs.use (". / main.js") / / main.js define (function (require, exports, module) {const foo = require (". / foo") console.log ("main:", foo)}) / / foo.js define (function (require, exports, module) {const name = "zh" const age = 22 function sum (num1) Num2) {return num1 + num2} / / exports.name = name / / exports.age = age module.exports = {name, age, sum}}) ES Module

There are some differences between the modularization of ES Module and CommonJS:

On the one hand, it uses the import and export keywords to achieve modularization.

On the other hand, it adopts static analysis in compilation time, and also adds dynamic reference.

Export is responsible for exporting the content within the module.

Import is responsible for importing content from other modules.

Adopting ES Module will automatically adopt strict mode: use strict.

Basic use

/ / index.html / / foo.js let obj = {name: "zh", age: 22} export default sum / / main.js import foo from'. / foo.js' console.log (foo)

When the html file loads the entry file, you need to specify type as module.

When opening a html file, you need to turn on the local service instead of directly opening it and running it on the browser.

This is explained on MDN:

You need to pay attention to local testing-if you load a Html file locally (such as a file with a file:// path), you will encounter CORS errors because of the Javascript module security requirements.

You need to test it through a server.

Exports keyword

The export keyword exports variables, functions, classes, etc., from a module.

We want to export all the other contents, which can be as follows:

Method 1: add the export keyword directly before the statement declaration.

Export const name = "zh" export const age = 22

Method 2: put all the identifiers that need to be exported into {} after export. Note: {} here is not an enhancement of the literal amount of objects in ES6, and {} does not represent an object. So: export {name: name} is the wrong way to write it.

Const name = "zh" const age = 22 function foo () {console.log ("foo function")} export {name, age, foo}

Method 3: give an alias to the identifier when exporting. (basically useless, generally aliases in the import file). Then you can only use an alias to get it in the import file.

Export {name as fName, age as fAge, foo as fFoo} import keyword

The import keyword is responsible for importing content from another module.

There are also several ways to import content:

Method 1: import {identifier list} from 'module'. Note: {} here is not an object either, it just stores the contents of the imported identifier list.

Import {name, age} from ". / foo.js"

Method 2: alias the identifier when importing.

Import {name as fName, age as fAge} from'. / foo.js'

Method 3: put the module function on a module function object (a module object) through *. And then use it by aliasing it.

Import * as foo from'. / foo.js'export combined with import

Represents import and export.

Import {add, sub} from'. / math.js' import {otherProperty} from'. / other.js' export {add, sub, otherProperty}

Equivalent to

/ / all imported files will be exported to export {add, sub} from'. / math.js' export {otherProperty} from'. / other.js'

Equivalent to

Export * from'. / math.js' export * from'. / other.js'

Why would you do that?

When developing and encapsulating a library, we usually want to put all the exposed interfaces in one file. This is convenient to specify a unified interface specification, but also easy to read. At this point, we can use export in combination with import.

Default usage

The named exports features we learned earlier are named exports (export):

The name was specified when exporting the export.

You need to know the specific name when importing import.

There is also an export called default export (default export)

/ / foo.js const name = "zh" cconst age = 22 export {name, / / or such default export / / age as default} export default age / / import statement: imported default export import foo, {name} from'. / foo.js' console.log (foo, name) / / 22 zh

By default, you do not need to specify a name when exporting export.

You don't need to use {} when importing, and you can specify the name yourself.

It also facilitates us to interoperate with existing specifications such as CommonJS.

Note: there can be only one default export (default export) in a module.

Import function

Loading a module through import cannot be put into logical code, such as:

If (true) {import foo from'. / foo.js'}

Why did this happen?

This is because ES Module must be aware of its dependencies when it is parsed by the JS engine.

Since the js code does not run at all at this time, it cannot be based on the execution of the code in making if-like judgments.

But in some cases, we do want to load a module dynamically:

If you choose the path to load the module dynamically according to different conditions.

At this point, we need to use the import () function to load dynamically. The result returned by the import function is a Promise.

Import (". / foo.js") .then (res = > {console.log ("res:", res.name)})

A new property has been added to es11. The meta property itself is also an object: {url: "the path where the current module is located"}

Parsing flow of console.log (import.meta) ES Module

How is ES Module parsed by browsers so that modules can refer to each other?

The parsing process of ES Module can be divided into three phases:

Phase 1: build (Construction), find the js file based on the address, download it, and parse it into a module record (Module Record).

Stage 2: Instantiation, instantiate the module record, allocate memory space, parse the import and export statements of the module, and point the module to the corresponding memory address.

Phase 3: Evaluation, run the code, calculate the value, and populate the value into the memory address.

Phase one:

Stages two and three:

Therefore, you can see from the above that in the export file, changing the value of the variable will affect the value in the import file. And the import file is restricted from modifying the value of the exported file.

The characteristic of JavaScript 1.JavaScript is mainly used to add interactive behavior to HTML pages. 2.JavaScript can be embedded directly into HTML pages, but writing as a separate js file facilitates the separation of structure and behavior. 3.JavaScript has cross-platform features and can run on multiple platforms with the support of most browsers.

How to understand the modularity in JavaScript advanced grammar is shared here. I hope the above content can be helpful to you and 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.