For example, if a company needs to operate normally, there are marketing department, technology department, personnel department, etc. each department is equivalent to a module. In the front-end project, there are modules such as special network request module, error handling module and special rendering module.
The traditional approach will introduce multiple js scripts, which are under the global scope, which will easily lead to global scope variable conflict (such as variable conflict with the same name) and some unpredictable things. For example:
/*moduleA.js in*/
var a=10;
/*moduleB.js in*/
var a=11;
/*index.html in*/
<body>
<script src="./moduleA.js"></script>
<script src="./moduleB.js"></script>
<script src="./moduleC.js"></script>
</body>
Copy code
When the above conflict occurs, can the value of a be determined—— No!
Then someone came up with the idea that each js script uses an object package to form a local scope.
// Define the local scope in the module, taking moduleA as an example
var Susan = {name: "susan",
sex: "female",
tell: function(){ console.log("im susan")}
}
Copy code
However, there are serious problems, that is, the value in the object can be changed, and the internal security of module attributes cannot be guaranteed. For example, the situation of user name, password and other data is very serious.
So it is improved to the form of immediate execution function and closure.
// Define the closure scope (module scope) in the module. Take moduleA as an example
var SusanModule = (function(){var name = "susan"
var sex = "female"
functioon tell(){//So you can't change the data console.log("I'm ", this.name)}
})()
Copy code
We further improve the writing method to write the parameter window for the immediate execution function.
// Define the closure scope (module scope) in the module. Take moduleA as an example
(function(window){var name = "susan"
var sex = "female"
functioon tell(){ console.log("I'm ", this.name)}
window.susanModule = {tell}})(window)// Pass window as a parameter to
//////////////////////
//test
window.susanModule.tell(); //im susan
Copy code
This is probably the early form of modularization.
Current modularization schemes include:
- AMD (Asynchronous Module Definition)
//The approximate form is as follows
//definition
define("mymodule", ["dep1", "dep2"], function(d1, d2) {});
// load
require(["module", "../file"], function(module, file) {});
Copy code
- CommonJs: dedicated to Node.js. The core idea of this scheme is to allow modules to synchronously load other dependent modules through the require scheme, and expose the required interfaces through exports or module.exports.
// Reference through the require function
const math = require("./math");// Export it through exports
exports.getSum = function(a,b){return a + b;
}
Copy code
- ES6 Module: the biggest feature of this scheme is static. The advantage of static is that the dependency of the module and the input and output variables can be determined during compilation. Both CommonJs and AMD mentioned above can only determine these things at run time.
// Reference through the import function
import math from "./math";
// Export it through export
export function sum(a, b){return a + b;
}
Copy code
In addition, talk about the difference between ES6 modularity and CommonJs modularity:
- The CommonJS module outputs a copy of the value, and the ES6 module outputs a reference to the value.
Note: the CommonJS module outputs a copy of the value, that is, once a value is output, changes within the module will not affect the value
ES6 module is a dynamic reference and will not cache values. Variables in the module are bound to its module.
- CommonJS module is loaded at run time, and ES6 module is the output interface at compile time.
Reason: CommonJS loads an object (i.e. module.exports attribute), which will not be generated until the script runs. And ` ES6
A module is not an object. Its external interface is just a static definition, which will be generated in the static parsing phase of the code.
- The require() of the CommonJS module is a synchronous loading module, and the import command of the ES6 module is an asynchronous loading. There is an independent module dependent parsing phase.
Front end modularization mainly solves two problems: "namespace conflict" and "file dependency management".
What does it have to do with introducing webpack?
In webpack, everything is a module. We usually use 'ES' in modular development
The Module or CommonJS specification exports or introduces dependent modules. When the webpack is packaged and compiled, it will be replaced with its own webpack_require ` to implement the introduction and export of modules, so as to realize the Module cache mechanism and smooth out some differences between different Module specifications.