模块化是一种主流的代码组织方式，是一种思想，它将代码依据不同的功能分成不同的模块来提高开发效率，降低维护成本。
模块化的演变
- stage1-文件划分方式
// 具体做法就是将每个功能及其相关状态数据各自单独放到不同的文件中，
// 约定每个文件就是一个独立的模块，
// 使用某个模块就是将这个模块引入到页面中，然后直接调用模块中的成员（变量 / 函数）
<script src="module-a.js"></script>
<script src="module-b.js"></script>
<script>
// 命名冲突
method1()
// 模块成员可以被修改
name = 'foo'
</script>
// module-a.js
var name = 'module-a'
function method1 () {
console.log(name + '#method1')
}
function method2 () {
console.log(name + '#method2')
}
缺点十分明显：
污染全局变量
容易产生命名冲突
无法管理模块与模块之间的依赖关系
完全依靠约定，项目一旦上了体量就不行了。
- stage2-命名空间方式
// 具体做法就是在第一阶段的基础上，通过将每个模块「包裹」为一个全局对象的形式实现，
// 有点类似于为模块内的成员添加了「命名空间」的感觉。
<script src="module-a.js"></script>
<script src="module-b.js"></script>
<script>
moduleA.method1()
moduleB.method1()
// 模块成员可以被修改
moduleA.name = 'foo'
</script>
// module-a.js
var moduleA = {
name: 'module-a',
method1: function () {
console.log(this.name + '#method1')
},
method2: function () {
console.log(this.name + '#method2')
}
}
通过「命名空间」减小了命名冲突的可能，
但是同样没有私有空间，所有模块成员也可以在模块外部被访问或者修改，而且也无法管理模块之间的依赖关系。
- stage3-使用立即执行函数
// 使用立即执行函数表达式为模块提供私有空间
// 具体做法就是将每个模块成员都放在一个函数提供的私有作用域中，
// 对于需要暴露给外部的成员，通过挂在到全局对象上的方式实现
// 还利用立即执行函数的参数传递模块依赖项。
<script src="https://unpkg.com/jquery"></script>
<script src="module-a.js"></script>
<script src="module-b.js"></script>
<script>
moduleA.method1()
moduleB.method1()
// 模块私有成员无法访问
console.log(moduleA.name) // => undefined
</script>
// module-a.js
(function ($) {
var name = 'module-a'
function method1 () {
console.log(name + '#method1')
$('body').animate({ margin: '200px' })
}
function method2 () {
console.log(name + '#method2')
}
window.moduleA = {
method1: method1,
method2: method2
}
})(jQuery)
有了私有成员的概念，私有成员只能在模块成员内通过闭包的形式访问。
参数传递模块依赖项，使得模块之间的关系变得更加明显
- stage4-Require.js 提供了 AMD 模块化规范
上面的方式还有问题就是，需要手动的维护引入模块
// 如果不需要module-a的方法了，还要记得删掉src="module-a.js"
<script src="https://unpkg.com/jquery"></script>
<script src="module-a.js"></script>
<script src="module-b.js"></script>
所以我们还需要一段公共的代码，通过代码，去自动加载模块就更好了
模块化规范的出现
模块化标准：commonJS规范，它是Node提出的一套标准，在nodejs当中，所有的模块必须要遵循commonJS规范。
commonJS约定了：
- 一个文件就是一个模块
- 每个模块都有单独的作用域
- 通过module.exports导出成员
- 通过require函数载入模块
commonJS是以同步方式加载模块，启动时全部引入，它是适用于Node的，Node的机制就是在启动时加载模块，执行过程是不需要去加载的，它只会使用到模块。
但是在浏览器中并不适用，它必然导致效率低下，因为每一次页面加载，都会有大量的同步任务出现，所以早期的前端模块化并没有选择commonJS，而是专门为浏览器端，结合浏览器的特点，重新设计了一个规范，AMD（Asynchronous Module Definition）异步的模块定义规范，然后出了一个很出名的库，Require.js。
Require.js 还有加载模块的功能，所以它就是「模块化标准 + 模块加载器」
// 定义一个模块
// module1 模块名字
// ['jquery', './module2'] 依赖模块
// function 导出函数
define('module1', ['jquery', './module2'], function ($, module2) {
return {
start: function () {
$('body').animate({ margin: '200px' })
module2()
}
}
})
// 引入模块并使用
require(['./modules/module1'], function (module1) {
module1.start()
})
// 原理也是创建script标签，通过src引入
但是，AMD使用起来相对复杂，除了业务代码还要写大量的Require.js。
我觉得这些历史对于在和平时期才接触前端的我们很重要。
模块化标准规范
现如今前端的模块化已经基本统一了。
浏览器端：ES Modules（ES2015中定义的模块系统）
Node端：CommonJS
ES Modules在刚出来时没有任何浏览器支持，随之webpack等打包工具的出现，它才随之流行开来，目前来说ES Modules是最主流的前端模块化方案了，相比AMD这种社区提出来的开发规范，ES Modules可以说是语言层面上实现了模块化，现在已经有部分浏览器直接支持ES Modules了。
ES Modules
基本特性：
<body>
<!-- 通过给 script 添加 type = module 的属性，就可以以 ES Module 的标准执行其中的 JS 代码了 -->
<script type="module">
console.log('this is es module')
</script>
<!-- 1. ESM 自动采用严格模式，忽略 'use strict' -->
<script type="module">
console.log(this)
</script>
<!-- 2. 每个 ES Module 都是运行在单独的私有作用域中 -->
<script type="module">
var foo = 100
console.log(foo)
</script>
<script type="module">
console.log(foo)
</script>
<!-- 3. ESM 是通过 CORS 的方式请求外部 JS 模块的 -->
<!-- <script type="module" src="https://unpkg.com/jquery@3.4.1/dist/jquery.min.js"></script> -->
<!-- 4. ESM 的 script 标签会延迟执行脚本,相当于defer属性 -->
<script type="module" defer src="demo.js"></script>
<p>需要显示的内容</p>
</body>
导入导出：
// a.js导出
var name = 'foo module'
class Person
export { name, Person }
// b.js导入
import { name, hello, Person } from './module.js'
// a.js导出
var name = 'foo module'
export default name
// b.js导入
import name from './module.js'
注意
1.导出是将值的引用关系导出，不是完全复制了一份。比如我将a.js中name在1s后又改成abc，b.js中1.5s后打印name也会变成abc。
2.导出的成员是一个只读的，并不能在模块的外部修改，比如在b.js中 name = 123会报错
// import其他常用用法
import './module.js' // 只执行模块，不用提取成员
// 动态导入
import ('./module.js').then((module)=>{}) // 执行完模块后返回promise
// 支持cdn导入
import { name } from 'http://localhost:3000/04-import/module.js'
兼容性改善，Polyfill
ES Module in Node
node 8.5版本后，开始支持ES Module
// 第一，将文件的扩展名由 .js 改为 .mjs；
// 第二，启动时需要额外添加 `--experimental-modules` 参数；
import { foo, bar } from './module.mjs'
console.log(foo, bar)
// 此时我们也可以通过 esm 加载内置模块了
import fs from 'fs'
fs.writeFileSync('./foo.txt', 'es module working')
// 也可以直接提取模块内的成员，内置模块兼容了 ESM 的提取成员方式
import { writeFileSync } from 'fs'
writeFileSync('./bar.txt', 'es module working')
// 对于第三方的 NPM 模块也可以通过 esm 加载
import _ from 'lodash'
ES Module 与 commonJS
image.png
- ES Module 中可以导入 CommonJS 模块
- 不能在 CommonJS 模块中通过 require 载入 ES Module
- CommonJS始终只会导出一个默认成员
- 不能直接提取成员，注意 import 不是解构导出对象
有人说可以在CommonJS中require 载入 ES Module，是因为你的webpack帮你编译了。
ES Module 与 commonJS的区别
// cjs.js
// 当前文件的绝对路径
console.log(__filename)
// 当前文件所在目录
console.log(__dirname)
// =>/Users/.../.cjs.js
// =>/Users/.../differences
// 都是可以输出的,因为在commonJS中__filename相当于全局变量
// 其实是commonJS把这些包装成函数后，通过参数提供的成员
// esm.mjs
console.log(__filename) // 报错
// 解决
import { fileURLToPath } from 'url'
import { dirname } from 'path'
const __filename = fileURLToPath(import.meta.url)
const __dirname = dirname(__filename)
console.log(__filename)
console.log(__dirname)
网友评论