# 什么是模块化?
-
到底什么是模块化、模块化开发呢?
- 事实上模块化开发最终的目的是将程序划分成一个个小的结构;
- 这个结构中编写属于自己的逻辑代码,有自己的作用域,不会影响到其他的结构;
- 这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用;
- 也可以通过某种方式,导入另外结构中的变量、函数、对象等;
-
上面说提到的结构,就是模块;按照这种结构划分开发程序的过程,就是模块化开发的过程;
-
无论你多么喜欢 JavaScript,以及它现在发展的有多好,它都有很多的缺陷:
- 比如 var 定义的变量作用域问题;
- 比如 JavaScript 的面向对象并不能像常规面向对象语言一样使用 class;
- 比如 JavaScript 没有模块化的问题;
-
Brendan Eich 本人也多次承认过 JavaScript 设计之初的缺陷,但是随着 JavaScript 的发展以及标准化,存在的缺陷问题基本都得到了完善。
-
无论是 web、移动端、小程序端、服务器端、桌面应用都被广泛的使用;
# 模块化的历史
- 在网页开发的早期,Brendan Eich 开发 JavaScript 仅仅作为一种脚本语言,做一些简单的表单验证或动画实现等,那个时候代码还是很少的:
- 这个时候我们只需要讲 JavaScript 代码写到 <script> 标签中即可;
- 并没有必要放到多个文件中来编写;甚至流行:通常来说 JavaScript 程序的长度只有一行。
- 但是随着前端和 JavaScript 的快速发展,JavaScript 代码变得越来越复杂了:
- ajax 的出现,前后端开发分离,意味着后端返回数据后,我们需要通过 JavaScript 进行前端页面的渲染;
- SPA 的出现,前端页面变得更加复杂:包括前端路由、状态管理等等一系列复杂的需求需要通过 JavaScript 来实现;
- 包括 Node 的实现,JavaScript 编写复杂的后端程序,没有模块化是致命的硬伤;
- 所以,模块化已经是 JavaScript 一个非常迫切的需求:
- 但是 JavaScript 本身,直到 ES6(2015)才推出了自己的模块化方案;
- 在此之前,为了让 JavaScript 支持模块化,涌现出了很多不同的模块化规范:AMD、CMD、CommonJS 等;
# 没有模块化带来的问题
-
早期没有模块化带来了很多的问题:比如命名冲突的问题
-
当然,我们有办法可以解决上面的问题:立即函数调用表达式(IIFE)
- IFE (Immediately Invoked Function Expression)
-
但是,我们其实带来了新的问题:
- 第一,我必须记得每一个模块中返回对象的命名,才能在其他模块使用过程中正确的使用;
- 第二,代码写起来混乱不堪,每个文件中的代码都需要包裹在一个匿名函数中来编写;
- 第三,在没有合适的规范情况下,每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况;
-
举个栗子
这是 Saber 的 js 文件
var moduleSaber = (function() { | |
var name = "saber" | |
var isFlag = true | |
return { | |
name, | |
isFlag | |
} | |
})() |
这是 Lain 的 js 文件
var moduleLain = (function() { | |
var name = "lain" | |
var isFlag = false | |
return { | |
name, | |
isFlag | |
} | |
})() |
- 这是执行的文件,执行代码引用自己对应的模块名,虽然可以做到模块化,但依旧不方便管理以及会引出其他的问题!
(function() { | |
if (moduleSaber.isFlag) { | |
console.log("我的名字是" + moduleSaber.name) | |
} | |
})() |
- 所以,我们会发现,虽然实现了模块化,但是我们的实现过于简单,并且是没有规范的。
- 我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码;
- 这个规范中应该包括核心功能:模块本身可以导出暴露的属性,模块又可以导入自己需要的属性;
- JavaScript 社区为了解决上面的问题,涌现出一系列好用的规范,接下来我们就学习具有代表性的一些规范。
# CommonJS 规范和 Node 关系
- 到底什么是模块化、模块化开发呢?
- 事实上模块化开发最终的目的是将程序划分成一个个小的结构;
- 这个结构中编写属于自己的逻辑代码,有自己的作用域,不会影响到其他的结构;
- 这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用;
- 也可以通过某种方式,导入另外结构中的变量、函数、对象等;
- 上面说提到的结构,就是模块;按照这种结构划分开发程序的过程,就是模块化开发的过程;
- 无论你多么喜欢 JavaScript,以及它现在发展的有多好,它都有很多的缺陷:
- 比如 var 定义的变量作用域问题;
- 比如 JavaScript 的面向对象并不能像常规面向对象语言一样使用 class;
- 比如 JavaScript 没有模块化的问题;
- Brendan Eich 本人也多次承认过 JavaScript 设计之初的缺陷,但是随着 JavaScript 的发展以及标准化,存在的缺陷问题基本都得到了完善。
- 无论是 web、移动端、小程序端、服务器端、桌面应用都被广泛的使用
# CommonJS 基本使用
- 这是 lain 的 js 文件
const name = "lain" | |
const age = 16 | |
function sum(num1, num2) { | |
return num1 + num2 | |
} | |
// 1. 导出方案 module.exports | |
module.exports = { | |
name, | |
age, | |
sum | |
} |
- 这是 main js 文件,module.exports 导出的是一个对象 所以可以解构赋值
// 使用另外一个模块导出的对象,那么就要进行导入 require | |
const { name, age, sum } = require("./lain.js") | |
console.log(name) // lain | |
console.log(age) // 16 | |
console.log(sum(20, 30)) // 50 |
# CommonJS 原理
- 这是 lain 的 js 文件
- 通过 module.exports 向外暴露
const lain = { | |
name: "lain", | |
age: 16 | |
} | |
// 下面的 main 将 lain.name 改变为 saber,这里也会被改变! | |
setTimeout(() => { | |
console.log(lain.name) // saber | |
}, 2000) | |
module.exports = lain |
- 这是 main js 文件
- require 相等于
function require(id){ return module.exports }
module.exports = lain
、require("./lain.js")
与lain
指向的都是同一个地址,它们是相等的关系
const lain = require("./lain.js") | |
console.log(lain) // { name: 'lain', age: 16 } | |
setTimeout(() => { | |
lain.name = "saber" | |
console.log(lain) // { name: 'saber', age: 16 } | |
}, 1000) |
- 所以通过上面代码验证是能够看出来的,它们都是引用赋值,因此它们都是同一个对象。
# exports 导出
- 注意:exports 是一个对象,我们可以在这个对象中添加很多个属性,添加的属性会导出;
//lain.js 文件 | |
const name = "lain" | |
const age = 16 | |
//exports 导出 | |
exports.name = name | |
exports.age = age |
- 另外一个文件中可以导入:
//main.js 文件 | |
const lain = require("./lain.js") | |
console.log(lain.name) // lain | |
console.log(lain.age) // 16 |
- 上面这行完成了什么操作呢?理解下面这句话,Node 中的模块化一目了然
- 意味着 main 中的 lain 变量等于 exports 对象;
- 也就是 require 通过各种查找方式,最终找到了 exports 这个对象;
- 并且将这个 exports 对象赋值给了 lain 变量;
- lain 变量就是 exports 对象了;
// 源码逻辑 | |
module.exports = {} | |
exports = module.exports | |
// 这样的操作相当于就是往 module.exports 里面添加 | |
exports.name = name | |
exports.age = age |
# module.exports
-
但是 Node 中我们经常导出东西的时候,又是通过 module.exports 导出的:
- module.exports 和 exports 有什么关系或者区别呢?
-
我们追根溯源,通过维基百科中对 CommonJS 规范的解析:
- CommonJS 中是没有 module.exports 的概念的;
- 但是为了实现模块的导出,Node 中使用的是 Module 的类,每一个模块都是 Module 的一个实例,也就是 module;
- 所以在 Node 中真正用于导出的其实根本不是 exports,而是 module.exports;
- 因为 module 才是导出的真正实现者;
-
但是,为什么 exports 也可以导出呢?
- 这是因为 module 对象的 exports 属性是 exports 对象的一个引用;
- 也就是说 module.exports = exports = main 中的 lain;
exports.name = name | |
exports.age = age | |
exports.sum = sum | |
// 这样导出的它们的引用地址明显不一样,所以它导出的是一个空对象 | |
module.exports = {} |
# require 细节
-
我们现在已经知道,require 是一个函数,可以帮助我们引入一个文件(模块)中导出的对象。
-
那么,require 的查找规则是怎么样的呢?
-
https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together
-
这里我总结比较常见的查找规则:导入格式如下:require (X)
# 情况一
- X 是一个 Node 核心模块,比如 path、http...
const path = require("path") | |
const fs = require("fs") | |
path.resolve() | |
path.extname() |
- 直接返回核心模块,并且停止查找
# 情况二
- X 是以 ./ 或 ../ 或 /(根目录)开头的
// 路径 | |
const lain = require("./lain") | |
// 根路径 | |
const lain = require("/lain") |
-
第一步:将 X 当做一个文件在对应的目录下查找;
- 如果有后缀名,按照后缀名的格式查找对应的文件
- 如果没有后缀名,会按照如下顺序:
- 直接查找文件 X
- 查找 X.js 文件
- 查找 X.json 文件
- 查找 X.node 文件
-
第二步:没有找到对应的文件,将 X 作为一个目录
- 查找目录下面的 index 文件
- 查找 X/index.js 文件
- 查找 X/index.json 文件
- 查找 X/index.node 文件
- 查找目录下面的 index 文件
-
如果没有找到,那么报错:not found
# 情况三
-
情况三:直接是一个 X(没有路径),并且 X 不是一个核心模块
-
/Users/coderwhy/Desktop/Node/TestCode/04_learn_node/05_javascript-module/02_commonjs/main.js 中编写 require ('why’)
-
如果上面的路径中都没有找到,那么报错:not found
// 不是路径也不是核心模块
const axios = require("axios")
// 会打印出许多路径,上面的代码会向当前文件夹 node_modules 查找
// 如果没有找到,则会取上上次,依次类推最终路径到当前根文件夹所在盘的 node_modules 最终都没找到就会报错 not found
console.log(module.paths)
# 模块的加载过程
# 结论一:模块在被第一次引入时,模块中的js代码会被运行一次
- foo 文件
console.log("foo中的代码被运行") |
- main 文件
console.log("main.js代码开始运行") // 1.main.js 代码开始运行 | |
require("./foo") // 2.foo 中的代码被运行 | |
console.log("main.js代码后续运行") // 3.main.js 代码后续运行 |
# 结论二:模块被多次引入时,会缓存,最终只加载(运行)一次
-
为什么只会加载运行一次呢?
-
这是因为每个模块对象 module 都有一个属性:loaded。
-
为 false 表示还没有加载,为 true 表示已经加载;
-
foo 文件
console.log("foo中的代码被运行") |
- main 文件
console.log("main.js代码开始运行") // 1.main.js 代码开始运行 | |
// 2.foo 中的代码被运行 且只会被运行一次 | |
require("./foo") | |
require("./foo") | |
console.log("main.js代码后续运行") // 4.main.js 代码后续运行 |
# 结论三:如果有循环引入,那么加载顺序是什么?
- 如果出现右图模块的引用关系,那么加载顺序是什么呢?
- 这个其实是一种数据结构:图结构;
- 图结构在遍历的过程中,有深度优先搜索(DFS, depth first search)和广度优先搜索(BFS, breadth first search)
# CommonJS 规范缺点
- CommonJS 加载模块是同步的:
- 同步的意味着只有等到对应的模块加载完毕,当前模块中的内容才能被运行;
- 这个在服务器不会有什么问题,因为服务器加载的 js 文件都是本地文件,加载速度非常快;
- 如果将它应用于浏览器呢?
- 浏览器加载 js 文件需要先从服务器将文件下载下来,之后再加载运行;
- 那么采用同步的就意味着后续的 js 代码都无法正常运行,即使是一些简单的 DOM 操作;
- 所以在浏览器中,我们通常不使用 CommonJS 规范:
- 当然在 webpack 中使用 CommonJS 是另外一回事;
- 因为它会将我们的代码转成浏览器可以直接执行的代码;
- 在早期为了可以在浏览器中使用模块化,通常会采用 AMD 或 CMD:
- 但是目前一方面现代的浏览器已经支持 ES Modules,另一方面借助于 webpack 等工具可以实现对 CommonJS 或者 ESModule 代码的转换;
- 而且 AMD 和 CMD 已经使用非常少了
# AMD 规范
-
AMD 主要是应用于浏览器的一种模块化规范:
-
AMD 是 Asynchronous Module Definition(异步模块定义)的缩写;
-
它采用的是异步加载模块;
-
事实上 AMD 的规范还要早于 CommonJS,但是 CommonJS 目前依然在被使用,而 AMD 使用的较少了;
-
-
我们提到过,规范只是定义代码的应该如何去编写,只有有了具体的实现才能被应用:
- AMD 实现的比较常用的库是 require.js 和 curl.js
# require.js 的使用
-
第一步:下载 require.js
- 下载地址:https://github.com/requirejs/requirejs
- 找到其中的 require.js 文件;
-
第二步:定义 HTML 的 script 标签引入 require.js 和定义入口文件:
- data-main 属性的作用是在加载完 src 的文件后会加载执行该文件
<script src="./lib/require.js" data-main="./index.js"></script> |
foo.js 文件
define(function() { | |
const name = "lain" | |
const age = 16 | |
return { | |
name, | |
age | |
} | |
}) |
bar.js 文件
// ["foo"] 依赖 foo 模块 先加载 foo 模块 | |
define(["foo"], function(foo) { | |
console.log("--------") // 1.-------- | |
require(["foo"], function(foo) { | |
console.log("bar:", foo) // 4.bar: {name: 'lain', age: 16} | |
}) | |
console.log("bar:", foo) // 2.bar: {name: 'lain', age: 16} | |
}) |
main.js 文件
require.config({ | |
baseUrl: './src', | |
paths: { | |
foo: "./foo", | |
bar: "./bar" | |
} | |
}) | |
require(["foo", "bar"], function(foo) { | |
console.log("main:", foo) // 3.console.log("main:", foo) | |
}) |
# CMD 规范
- CMD 规范也是应用于浏览器的一种模块化规范:
- CMD 是 Common Module Definition(通用模块定义)的缩写;
- 它也采用了异步加载模块,但是它将 CommonJS 的优点吸收了过来;
- 但是目前 CMD 使用也非常少了;
- CMD 也有自己比较优秀的实现方案:
- SeaJS
# SeaJS 的使用
- 第一步:下载 SeaJS
- 下载地址:https://github.com/seajs/seajs
- 找到 dist 文件夹下的 sea.js
- 第二步:引入 sea.js 和使用主入口文件
- seajs 是指定主入口文件的
<script src="./lib/sea.js"></script> | |
<script>seajs.use("./src/main.js")</script> |
foo.js 文件
define(function(require, exports, module) { | |
const name = "why" | |
const age = 18 | |
module.exports = { | |
name, | |
age | |
} | |
}) |
main.js 文件
define(function(require, exports, module) { | |
const foo = require("./foo") | |
console.log("main:", foo) // main: {name: 'why', age: 18} | |
}) |