|
目录
模块化
立即执行函数
AMD&CMD
CommonJS
模块化
首先先明确为什么要使用模块化，使用模块化的好处是什么？
使用模块化可以解决：
- 命名冲突
- 提高复用性
- 提高代码的可维护性
立即执行函数
使用立即执行函数实现模块化是常见的手段，通过函数作用域解决了命名冲突，污染全局作用域的问题
(function(globalVariable){
globalVariable.test = function() {}
//....声明变量，函数都不会污染全局作用域
})
AMD&CMD
目前两种实现方式已经很少见，使用方式如下
//AMD
define(['./a','./b'],function(a,b) {
? ? ? ? a.do()
? ? ? ? b.do()
})
//CMD
define(function(require,export,module) {
//加载模块，可以把require写在函数体的任意地方实现延迟加载
var a = require('./a')
a.doSomething()
})
CommonJS
CommonJS最早是在Node中使用，目前仍然广泛应用，如webpack中就可以看到它的身影，目前Node中的模块管理已经与CommonJS有一些区别了。
//a.js
module.export = {
a:1
}
//a.js的另一种写法
exports.a =1
//b.js
var module = require('./a.js')
module.a //->log 1
require?
var module = require('./a.js')
module.a
// 这里其实就是包装了一层立即执行函数，这样就不会污染全局变量了，
// 重要的是 module 这里，module 是 Node 独有的一个变量
module.exports = {
a: 1
}
// module 基本实现
var module = {
id: 'xxxx', // 我总得知道怎么去找到他吧
exports: {} // exports 就是个空对象
}
// 这个是为什么 exports 和 module.exports 用法相似的原因
var exports = module.exports
var load = function (module) {
// 导出的东西
var a = 1
module.exports = a
return module.exports
};
// 然后当我 require 的时候去找到独特的
// id，然后将要使用的东西用立即执行函数包装下，over
export与module.exports用法相似，但是不可以对exports直接赋值。
因为var exports = modules.exports这句话表明了exports和module.exports享有相同的储存地址，通过改变对象的属性值会对二者都起作用，但是直接对exports赋值就会导致两者不在指向同一个内存地址，修改并不会对module.exports起作用。
ES Module
ES Module 是原生实现的模块化方案，与 CommonJS 有以下几个区别
- CommonJS 支持动态导入，也就是?
require(${path}/xx.js)，后者目前不支持，但是已有提案 - CommonJS 是同步导入，因为用于服务端，文件都在本地，同步导入即使卡住主线程影响也不大。而后者是异步导入，因为用于浏览器，需要下载文件，如果也采用同步导入会对渲染有很大影响
- CommonJS 在导出时都是值拷贝，就算导出的值变了，导入的值也不会改变，所以如果想更新值，必须重新导入一次。但是 ES Module 采用实时绑定的方式，导入导出的值都指向同一个内存地址，所以导入值会跟随导出值变化
- ES Module 会编译成?
require/exports?来执行的
|