JavaScript 模块化
什么是模块化呢?
- 那么,到底什么是模块化开发呢?
- 事实上模块化开发最终的目的是将程序划分成一个个小的结构;
- 这个结构中编写属于自己的逻辑代码,有自己的作用域,不会影响到其他的结构;
- 这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用;
- 也可以通过某种方式,导入另外结构中的变量、函数、对象等;
- 上面说提到的结构,就是模块;按照这种结构划分开发程序的过程,就是模块化开发的过程;
- 无论你多么喜欢
JavaScript
,以及它现在发展的有多好,我们都需要承认在Brendan Eich
用了10
天写出JavaScript
的时候, 它都有很多的缺陷:- 比如
var
定义的变量作用域问题; - 比如
JavaScript
的面向对象并不能像常规面向对象语言一样使用class
; - 比如
JavaScript
没有模块化的问题;
- 比如
Brendan Eich
本人也多次承认过JavaScript
设计之初的缺陷,但是随着JavaScript
的发展以及标准化,存在的缺陷问题基本都得到了完善。无论是web
、移动端、小程序端、服务器端、桌面应用都被广泛的使用;
早期的JavaScript
- 在网页开发的早期,
Brendan Eich
开发JavaScript
仅仅作为一种脚本语言,做一些简单的表单验证或动画实现等,那个时候代码还是很少的:- 这个时候我们只需要讲
JavaScript
代码写到<script>
标签中即可; - 并没有必要放到多个文件中来编写;甚至流行:通常来说
JavaScript
程序的长度只有一行。
- 这个时候我们只需要讲
- 但是随着前端和
JavaScript
的快速发展,JavaScript
代码变得越来越复杂了:ajax
的出现,前后端开发分离,意味着后端返回数据后,我们需要通过JavaScript
进行前端页面的渲染;SPA
的出现,前端页面变得更加复杂:包括前端路由、状态管理等等一系列复杂的需求需要通过JavaScript
来实现;- 包括
Node
的实现,JavaScript
编写复杂的后端程序,没有模块化是致命的硬伤;
- 所以,模块化已经是
JavaScript
一个非常迫切的需求:- 但是
JavaScript
本身,直到ES6(2015)
才推出了自己的模块化方案; - 在此之前,为了让
JavaScript
支持模块化,涌现出了很多不同的模块化规范:AMD
、CMD
、CommonJS
等;
- 但是
没有模块化带来很多的问题
-
早期没有模块化带来了很多的问题:比如命名冲突的问题
-
当然,我们有办法可以解决上面的问题:立即函数调用表达式
(IIFE)
IIFE (Immediately Invoked Function Expression)
-
但是,我们其实带来了新的问题:
- 第一,我必须记得每一个模块中返回对象的命名,才能在其他模块使用过程中正确的使用;
- 第二,代码写起来混乱不堪,每个文件中的代码都需要包裹在一个匿名函数中来编写;
- 第三,在没有合适的规范情况下,每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况;
-
所以,我们会发现,虽然实现了模块化,但是我们的实现过于简单,并且是没有规范的。
- 我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码;
- 这个规范中应该包括核心功能:模块本身可以导出暴露的属性,模块又可以导入自己需要的属性;
JavaScript
社区为了解决上面的问题,涌现出一系列好用的规范,接下来我们就学习具有代表性的一些规范。
CommonJS和Node
- 我们需要知道
CommonJS
是一个规范,最初提出来是在浏览器以外的地方使用,并且当时被命名为ServerJS
,后来为了体现它的广泛性,修改为CommonJS
,平时我们也会简称为CJS
。Node
是CommonJS
在服务器端一个具有代表性的实现;Browserify
是CommonJS
在浏览器中的一种实现;webpack
打包工具具备对CommonJS
的支持和转换;
- 所以,
Node
中对CommonJS
进行了支持和实现,让我们在开发node
的过程中可以方便的进行模块化开发:- 在
Node
中每一个js
文件都是一个单独的模块; - 这个模块中包括
CommonJS
规范的核心变量:exports
、module.exports
、require
; - 我们可以使用这些变量来方便的进行模块化开发;
- 在
- 前面我们提到过模块化的核心是导出和导入,
Node
中对其进行了实现:exports
和module.exports
可以负责对模块中的内容进行导出;require
函数可以帮助我们导入其他模块(自定义模块、系统模块、第三方库模块)中的内容;
案例设定
-
我们来看一下两个文件:
-
目录结构
-
新建文件夹
node
,在文件夹node
下面新建文件bar.js
和main.js
(入口文件) -
在
bar.js
中const name = "admin"; const sum = (a, b) => { return a + b; }; // 导出 exports.name = name; exports.sum = sum;
-
在
main.js
中const bar = require("./bar"); console.log(bar.name); console.log(bar.sum(10, 20));
// 或者解构导入 const { name, sum } = require("./bar"); console.log(name, sum(10, 20));
-
这个时候假如每次修改输出都需要在控制台打印
node main.js
,这样明显太烦,所以这里需要安装一个热部署nodemon
-
首先控制台初始化项目
npm init -y
-
安装热部署
npm i modemon
(局部装置、全局需要加-g
) -
配置脚本,在
package.json
中{ "name": "node", "version": "1.0.0", "description": "", "main": "main.js", "scripts": { "start": "nodemon main.js" }, "keywords": [], "author": "", "license": "ISC", "dependencies": { "nodemon": "^2.0.16" } }
-
控制台输出打印
npm start
这样随着文件的修改,保存就可以直接打印了
-
exports导出
-
注意:
exports
是一个对象,我们可以在这个对象中添加很多个属性,添加的属性会导出;// bar.js const name = "admin"; const sum = (a, b) => { return a + b; }; // 导出 exports.name = name; exports.sum = sum;
-
另外一个文件中可以导入:
// main.js const bar = require("./bar"); console.log(bar.name); console.log(bar.sum(10, 20));
上面这行完成了什么操作呢?理解下面这句话,
Node
中的模块化一目了然- 意味着
main
中的bar
变量等于exports
对象; - 也就是
require
通过各种查找方式,最终找到了exports
这个对象; - 并且将这个
exports
对象赋值给了bar
变量; bar
变量就是exports
对象了;
- 意味着
它们实际上是一个浅层拷贝
- 为了进一步论证,
bar
和exports
是同一个对象:- 所以,
bar
对象是exports
对象的浅拷贝(引用赋值); - 浅拷贝的本质就是一种引用的赋值而已;
- 所以,
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
中的bar
;
- 这是因为
-
案例分析
-
在
bar.js
中module.exports.age = 10;
-
在
main.js
中const { age } = require("./bar.js"); console.log(age);
-
控制台打印结果
-
require
-
我们现在已经知道,
require
是一个函数,可以帮助我们引入一个文件(模块)中导入的对象。 -
那么,
require
的查找规则是怎么样的呢? -
这里我总结比较常见的查找规则:导入格式如下:
require(X)
-
情况一:
X
是一个核心模块,比如path
、http
等内置模块- 直接返回核心模块,并且停止查找
-
情况二:
-
情况二:
X
是以./
或../
或/
(根目录)开头的 -
第一步:将
X
当做一个文件在对应的目录下查找;-
如果有后缀名,按照后缀名的格式查找对应的文件
require('./utils.js') // 这个时候它会直接去找对应的 utils.js 文件
-
如果没有后缀名,会按照如下顺序:
-
直接查找文件
X
-
查找
X.js
文件 -
查找
X.json
文件 -
查找
X.node
文件require("./utils"); // 直接查找 utils 文件 // 查找是否有 utils.js // 查找是否有 utils.json // 查找是否有 utils.node
-
-
-
第二步:没有找到对应的文件,将
X
作为一个目录-
查找目录下面的
index
文件-
查找
X/index.js
文件 -
查找
X/index.json
文件 -
查找
X/index.node
文件require("./utils"); // 查找utils目录下是否有 index.js // 查找utils目录下是否有 index.json // 查找utils目录下是否有 index.node
-
-
-
如果没有找到,那么报错:
not found
-
-
情况三:
-
情况三:直接是一个
X
(没有路径),并且X
不是一个核心模块(内置模块) -
会依次向上去找
node_modules
-
如果上面的路径中都没有找到,那么报错:
not found
-
CommonJS规范缺点
CommonJS
加载模块是同步的:- 同步的意味着只有等到对应的模块加载完毕,当前模块中的内容才能被运行;
- 这个在服务器不会有什么问题,因为服务器加载的
js
文件都是本地文件,加载速度非常快;
- 如果将它应用于浏览器呢?
- 浏览器加载
js
文件需要先从服务器将文件下载下来,之后在加载运行; - 那么采用同步的就意味着后续的
js
代码都无法正常运行,即使是一些简单的DOM
操作;
- 浏览器加载
- 所以在浏览器中,我们通常不使用
CommonJS
规范:- 当然在
webpack
中使用CommonJS
是另外一回事; - 因为它会将我们的代码转成浏览器可以直接执行的代码;
- 当然在
- 在早期为了可以在浏览器中使用模块化,通常会采用
AMD
或CMD
:- 但是目前一方面现代的浏览器已经支持
ES Modules
,另一方面借助于webpack
等工具可以实现对CommonJS
或者ES Module
代码的转换; AMD
和CMD
已经使用非常少了;
- 但是目前一方面现代的浏览器已经支持
认识 ESModule
JavaScript
没有模块化一直是它的痛点,所以才会产生我们前面学习的社区规范:CommonJS
、AMD
、CMD
等,所以在ES
推出自己的模块化系统时,大家也是兴奋异常。ES Module
和CommonJS
的模块化有一些不同之处:- 一方面它使用了
import
和export
关键字; - 另一方面它采用编译期的静态分析,并且也加入了动态引用的方式;
- 一方面它使用了
ES Module
模块采用export
和import
关键字来实现模块化:export
负责将模块内的内容导出;import
负责从其他模块导入内容;
- 了解:采用
ES Module
将自动采用严格模式:use strict
- 如果你不熟悉严格模式可以简单看一下
MDN
上的解析;
- 如果你不熟悉严格模式可以简单看一下
案例代码结构组件
-
这里我在浏览器中演示
ES6
的模块化开发:<script src="./modules/foo.js" type="module"></script> <script src="main.js" type="module"></script>
-
如果直接在浏览器中运行代码,会报如下错误:
-
这个在
MDN
上面有给出解释:https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Guide/Modules
- 你需要注意本地测试 — 如果你通过本地加载
Html
文件 (比如一个file://
路径的文件), 你将会遇到CORS
错误,因为Javascript
模块安全性需要。 - 你需要通过一个服务器来测试。
-
我这里使用的
VSCode
,VSCode
中有一个插件:Live Server
export 关键字
export
关键字将一个模块中的变量、函数、类等导出;- 我们希望将其他中内容全部导出,它可以有如下的方式:
- 方式一:在语句声明的前面直接加上
export
关键字 - 方式二:将所有需要导出的标识符,放到
export
后面的{}
中- 注意:这里的
{}
里面不是ES6
的对象字面量的增强写法,{}
也不是表示一个对象的; - 所以:
export {name: name}
,是错误的写法;
- 注意:这里的
- 方式三:导出时给标识符起一个别名
- 方式一:在语句声明的前面直接加上
import关键字
import
关键字负责从另外一个模块中导入内容- 导入内容的方式也有多种:
- 方式一:import {标识符列表} from ‘模块’;
- 注意:这里的{}也不是一个对象,里面只是存放导入的标识符列表内容;
- 方式二:导入时给标识符起别名
- 方式三:通过
*
将模块功能放到一个模块功能对象(a module object
)上
- 方式一:import {标识符列表} from ‘模块’;
Export和import结合使用
- 补充:
export
和import
可以结合使用 - 为什么要这样做呢?
- 在开发和封装一个功能库时,通常我们希望将暴露的所有接口放到一个文件中;
- 这样方便指定统一的接口规范,也方便阅读;
- 这个时候,我们就可以使用
export
和import
结合使用;
default用法
- 前面我们学习的导出功能都是有名字的导出(
named exports
):- 在导出
export
时指定了名字; - 在导入
import
时需要知道具体的名字;
- 在导出
- 还有一种导出叫做默认导出(
default export
)- 默认导出
export
时可以不需要指定名字; - 在导入时不需要使用
{}
,并且可以自己来指定名字; - 它也方便我们和现有的
CommonJS
等规范相互操作;
- 默认导出
- 注意:在一个模块中,只能有一个默认导出(
default export
);
import函数
-
通过import加载一个模块,是不可以在其放到逻辑代码中的,比如:
// 这样是不对的 不可行的 if(true) { import sub from './modules/foo.js'; }
-
为什么会出现这个情况呢?
- 这是因为
ES Module
在被JS
引擎解析时,就必须知道它的依赖关系; - 由于这个时候
js
代码没有任何的运行,所以无法在进行类似于if
判断中根据代码的执行情况;
- 这是因为
-
但是某些情况下,我们确确实实希望动态的来加载某一个模块:
- 如果根据不懂的条件,动态来选择加载模块的路径;
- 这个时候我们需要使用
import()
函数来动态加载;
CommonJS的加载过程
-
CommonJS
模块加载js
文件的过程是运行时加载的,并且是同步的:-
运行时加载意味着是
js
引擎在执行js
代码的过程中加载模块; -
同步的就意味着一个文件没有加载结束之前,后面的代码都不会执行;
// CommonJS 语句是可以写在逻辑代码里面的 const flag = true; if (flag) { const foo = require("./foo"); console.log("if语句继续执行"); }
-
-
CommonJS
通过module.exports
导出的是一个对象:- 导出的是一个对象意味着可以将这个对象的引用在其他模块中赋值给其他变量;
- 但是最终他们指向的都是同一个对象,那么一个变量修改了对象的属性,所有的地方都会被修改;
ES Module加载过程
-
ES Module
加载js
文件的过程是编译(解析)时加载的,并且是异步的:- 编译时(解析)时加载,意味着
import
不能和运行时相关的内容放在一起使用: - 比如
from
后面的路径需要动态获取; - 比如不能将
import
放到if
等逻辑语句的代码块中; - 所以我们有时候也称
ES Module
是静态解析的,而不是动态或者运行时解析的;
- 编译时(解析)时加载,意味着
-
异步的意味着:
JS
引擎在遇到import
时会去获取这个js
文件,但是这个获取的过程是异步的,并不会阻塞主线程继续执行;-
也就是说设置了
type=module
的代码,相当于在script
标签上也加上了async
属性; -
如果我们后面有普通的
script
标签以及对应的代码,那么ES Module
对应的js
文件和代码不会阻塞它们的执行;<script src="./modules/foo.js" type="module"></script> <!-- 这个js文件的代码不会被阻塞执行 可以同时执行 --> <script src="main.js" type="module"></script>
-