Modular

wang xiao bo 's photo
wang xiao bo
·Dec 4, 2021·

3 min read

Subscribe to my newsletter and never miss my upcoming articles

Using modularity can bring us the following benefits

  • Resolve naming conflicts
  • Provide reusability
  • Improve code maintainability

Execute function immediately

(function(globalVariable){
globalVariable.test = function() {}
// ... Declaring various variables and functions will not pollute the global scope
})(globalVariable)

CommonJS CommonJS was first used by Node and is still widely used. For example, you can see it in Webpack. Of course, the current module management in Node has some differences from CommonJS.

// b.js
module.exports = {
    b: 8
}
// or 
exports.b = 8

// c.js
var module = require('./b.js')
module.b // -> log 1

Because CommonJS will still be used, some difficult points will be analyzed here

var module = require('./b.js')
module.b
// Here is actually a layer of immediate execution function is wrapped, so that it will not pollute global variables,
// The important thing is module Here, module is a variable unique to Node
module.exports = {
b: 1
}
// module basic implementation
var module = {
id:'xxxx', // I have to know how to find him
exports: {} // exports is an empty object
}
// This is why exports and module.exports are similar in usage
var exports = module.exports
var load = function (module) {
// exported stuff
var b = 1
module.exports = b
return module.exports
};
// Then when I require to find the unique
// id, then wrap the things to be used with an immediate execution function, over

In addition, although exports and module.exports are similar in usage, they cannot be directly assigned to exports. Because the code of var exports = module.exports shows that exports and module.exports share the same address, changing the attribute value of the object will take effect for both, but if you assign a value to exports directly, the two will no longer point to the same address. A memory address, modification will not take effect on module.exports.

ES Module

ES Module is a natively implemented modular solution, which has the following differences from CommonJS

-CommonJS supports dynamic import, that is, require(${path}/xx.js), the latter does not currently support, but there are proposals -CommonJS is a synchronous import, because it is used on the server side, the files are all local, and the synchronous import has little effect even if the main thread is stuck. The latter is imported asynchronously, because it is used in a browser, and files need to be downloaded. If synchronous importing is also used, rendering will be greatly affected -CommonJS is a value copy when exporting. Even if the exported value changes, the imported value will not change, so if you want to update the value, you must import it again. However, ES Module uses real-time binding, and the imported and exported values ​​all point to the same memory address, so the imported value will follow the exported value. -ES Module will be compiled into require/exports to execute

// Introduce module API
import XXX from'./b.js'
import {XXX} from'./b.js'
// Export module API
export function b() {}
export default function() {}
 
Share this