
2025-04-19 日报 Day161

今日的鸡汤
我希望在繁华尽处,寻一抹静谧,泛舟湖上,三五好友,一壶老酒,家人作伴,唱歌会友。来吧,于绿野间、阳光下创造美好,治愈青春。
今日学习内容
1、JS 红皮书 P772-781 第二十六章:模块
今日笔记
1、模块: 现代 JavaScript 开发毋庸置疑会遇到代码量大和广泛使用第三方库的问题。解决这个问题的方案通常需要把代码拆分成很多部分,然后再通过某种方式将它们连接起来。
在 ECMAScript 6 模块规范出现之前,虽然浏览器原生不支持模块的行为,但迫切需要这样的行为。ECMAScript 同样不支持模块,因此希望使用模块模式的库或代码库必须基于 JavaScript 的语法和词法特性“伪造”出类似模块的行为。
因为 JavaScript 是异步加载的解释型语言,所以得到广泛应用的各种模块实现也表现出不同的形态。这些不同的形态决定了不同的结果,但最终它们都实现了经典的模块模式。
2、理解模块模式: 将代码拆分成独立的块,然后再把这些块连接起来可以通过模块模式来实现。这种模式背后的思想很简单:把逻辑分块,各自封装,相互独立,每个块自行决定对外暴露什么,同时自行决定引入执行哪些外部代码。不同的实现和特性让这些基本的概念变得有点复杂,但这个基本的思想是所有 JavaScript模块系统的基础。
- 模块标识符: 模块标识符是所有模块系统通用的概念。模块系统本质上是键/值实体,其中每个模块都有个可用于引用它的标识符。这个标识符在模拟模块的系统中可能是字符串,在原生实现的模块系统中可能是模块文件的实际路径。
将模块标识符解析为实际模块的过程要根据模块系统对标识符的实现。原生浏览器模块标识符必须提供实际 JavaScript 文件的路径。除了文件路径,Node.js 还会搜索 node_modules 目录,用标识符去匹配包含 index.js 的目录。 - 模块依赖: 模块系统的核心是管理依赖。指定依赖的模块与周围的环境会达成一种契约。本地模块向模块系统声明一组外部模块(依赖),这些外部模块对于当前模块正常运行是必需的。模块系统检视这些依赖,进而保证这些外部模块能够被加载并在本地模块运行时初始化所有依赖。
每个模块都会与某个唯一的标识符关联,该标识符可用于检索模块。这个标识符通常是 JavaScript文件的路径,但在某些模块系统中,这个标识符也可以是在模块本身内部声明的命名空间路径字符串。 - 模块加载: 加载模块的概念派生自依赖契约。当一个外部模块被指定为依赖时,本地模块期望在执行它时,依赖已准备好并已初始化。
在浏览器中,加载模块涉及几个步骤。加载模块涉及执行其中的代码,但必须是在所有依赖都加载并执行之后。如果浏览器没有收到依赖模块的代码,则必须发送请求并等待网络返回。收到模块代码之后,浏览器必须确定刚收到的模块是否也有依赖。然后递归地评估并加载所有依赖,直到所有依赖模块都加载完成。只有整个依赖图都加载完成,才可以执行入口模块。 - 入口: 相互依赖的模块必须指定一个模块作为入口(entry point),这也是代码执行的起点。这是理所当然的,因为 JavaScript 是顺序执行的,并且是单线程的,所以代码必须有执行的起点。入口模块也可能依赖其他模块,其他模块同样可能有自己的依赖。于是模块化 JavaScript 应用程序的所有模块会构成依赖图。
可以通过有向图来表示应用程序中各模块的依赖关系。
在 JavaScript 中,“加载”的概念可以有多种实现方式。因为模块是作为包含将立即执行的 JavaScript代码的文件实现的,所以一种可能是按照依赖图的要求依次请求各个脚本。对于前面的应用程序来说,下面的脚本请求顺序能够满足依赖图的要求: 模块加载是“阻塞的”,这意味着前置操作必须完成才能执行后续操作。 - 异步依赖: 因为 JavaScript 可以异步执行,所以如果能按需加载就好了。换句话说,可以让 JavaScript 通知模块系统在必要时加载新模块,并在模块加载完成后提供回调。在代码层面,可以通过下面的伪代码来实现:
// 在模块 A 里面
load(‘moduleB’).then(function(moduleB) {
moduleB.doStuff();
});
模块 A 的代码使用了 moduleB 标识符向模块系统请求加载模块 B,并以模块 B 作为参数调用回调。模块 B 可能已加载完成,也可能必须重新请求和初始化,但这里的代码并不关心。这些事情都交给了模块加载器去负责。 - 动态依赖: 有些模块系统要求开发者在模块开始列出所有依赖,而有些模块系统则允许开发者在程序结构中动态添加依赖。动态添加的依赖有别于模块开头列出的常规依赖,这些依赖必须在模块执行前加载完毕。
下面是动态依赖加载的例子:
if (loadCondition) {
require(‘./moduleA’);
}
动态依赖可以支持更复杂的依赖关系,但代价是增加了对模块进行静态分析的难度。 - 静态分析: 模块中包含的发送到浏览器的 JavaScript 代码经常会被静态分析,分析工具会检查代码结构并在不实际执行代码的情况下推断其行为。对静态分析友好的模块系统可以让模块打包系统更容易将代码处理为较少的文件。它还将支持在智能编辑器里智能自动完成。
更复杂的模块行为,例如动态依赖,会导致静态分析更困难。不同的模块系统和模块加载器具有不同层次的复杂度。至于模块的依赖,额外的复杂度会导致相关工具更难预测模块在执行时到底需要哪些依赖。 - 循环依赖: 要构建一个没有循环依赖的 JavaScript 应用程序几乎是不可能的,因此包括 CommonJS、AMD 和ES6 在内的所有模块系统都支持循环依赖。在包含循环依赖的应用程序中,模块加载顺序可能会出人意料。不过,只要恰当地封装模块,使它们没有副作用,加载顺序就应该不会影响应用程序的运行。
3、凑合的模块系统: 为按照模块模式提供必要的封装,ES6 之前的模块有时候会使用函数作用域和立即调用函数表达式(IIFE,Immediately Invoked Function Expression)将模块定义封装在匿名闭包中。模块定义是立即执行的,如下:
(function() {
// 私有 Foo 模块的代码
console.log(‘bar’);
})();
// bar
4、使用ES6之前的模块加载器: 在 ES6 原生支持模块之前,使用模块的 JavaScript 代码本质上是希望使用默认没有的语言特性。因此,必须按照符合某种规范的模块语法来编写代码,另外还需要单独的模块工具把这些模块语法与JavaScript 运行时连接起来。这里的模块语法和连接方式有不同的表现形式,通常需要在浏览器中额外加载库或者在构建时完成预处理。 - CommonJS: CommonJS 规范概述了同步声明依赖的模块定义。这个规范主要用于在服务器端实现模块化代码组织,但也可用于定义在浏览器中使用的模块依赖。CommonJS 模块语法不能在浏览器中直接运行。
注意 一般认为,Node.js的模块系统使用了CommonJS规范,实际上并不完全正确。Node.js使用了轻微修改版本的 CommonJS,因为 Node.js 主要在服务器环境下使用,所以不需要考虑网络延迟问题。考虑到一致性,本节使用 Node.js 风格的模块定义语法。
CommonJS 模块定义需要使用 require()指定依赖,而使用 exports 对象定义自己的公共 API。下面的代码展示了简单的模块定义:
var moduleB = require(‘./moduleB’);
module.exports = {
stuff: moduleB.doStuff();
};
无论一个模块在 require()中被引用多少次,模块永远是单例。在下面的例子中,moduleA 只会被打印一次。这是因为无论请求多少次,moduleA 只会被加载一次。
console.log(‘moduleA’);
var a1 = require(‘./moduleA’);
var a2 = require(‘./moduleA’);
console.log(a1 === a2); // true
在 CommonJS 中,模块加载是模块系统执行的同步操作。因此 require()可以像下面这样以编程方式嵌入在模块中:
console.log(‘moduleA’);
if (loadCondition) {
require(‘./moduleA’);
}
这里,moduleA 只会在 loadCondition 求值为 true 时才会加载。这个加载是同步的,因此 if()块之前的任何代码都会在加载 moduleA 之前执行,而 if()块之后的任何代码都会在加载 moduleA 之后执行。
注意,此模块不导出任何内容。即使它没有公共接口,如果应用程序请求了这个模块,那也会在加载时执行这个模块体。
module.exports 对象非常灵活,有多种使用方式。如果只想导出一个实体,可以直接给 module.exports 赋值:
module.exports = ‘foo’;
这样,整个模块就导出一个字符串,可以像下面这样使用:
var moduleA = require(‘./moduleB’);
console.log(moduleB); // ‘foo’
导出多个值也很常见,可以使用对象字面量赋值或每个属性赋一次值来实现:
// 等价操作:
module.exports = {
a: ‘A’,
b: ‘B’
};
module.exports.a = ‘A’;
module.exports.b = ‘B’; - 异步模块定义: CommonJS 以服务器端为目标环境,能够一次性把所有模块都加载到内存,而异步模块定义(AMD,Asynchronous Module Definition)的模块定义系统则以浏览器为目标执行环境,这需要考虑网络延迟的问题。AMD 的一般策略是让模块声明自己的依赖,而运行在浏览器中的模块系统会按需获取依赖,并在依赖加载完成后立即执行依赖它们的模块。
AMD 模块实现的核心是用函数包装模块定义。AMD 模块可以使用字符串标识符指定自己的依赖,而 AMD 加载器会在所有依赖模块加载完毕后立即调用模块工厂函数。与 CommonJS 不同,AMD 支持可选地为模块指定字符串标识符。
// ID 为’moduleA’的模块定义。moduleA 依赖 moduleB,
// moduleB 会异步加载
define(‘moduleA’, [‘moduleB’], function(moduleB) {
return {
stuff: moduleB.doStuff();
};
});
AMD 也支持 require 和 exports 对象,通过它们可以在 AMD 模块工厂函数内部定义 CommonJS风格的模块。这样可以像请求模块一样请求它们,但 AMD 加载器会将它们识别为原生 AMD 结构,而不是模块定义:
define(‘moduleA’, [‘require’, ‘exports’], function(require, exports) {
var moduleB = require(‘moduleB’);
exports.stuff = moduleB.doStuff();
});
动态依赖也是通过这种方式支持的:
define(‘moduleA’, [‘require’], function(require) {
if (condition) {
var moduleB = require(‘moduleB’);
}
});