现在前端技术日新月异,对于同一个问题痛点,各个时段有各自的解决方案,这就带来了很大差异。今天我就打算梳理js模块化的历史进程,讲一讲这些方案要做什么,怎么做。
现今的很多网页其实可以看做是功能丰富的应用,它们拥有着复杂的JavaScript代码和一大堆依赖包。当一个项目开发的越来越复杂的时候,你会遇到一些问题:命名冲突(变量和函数命名可能相同),文件依赖(引入外部的文件数目、顺序问题)等。
JavaScript发展的越来越快,超过了它产生时候的自我定位。这时候js模块化就出现了。
模块化开发是一种管理方式,是一种生产方式,一种解决问题的方案。他按照功能将一个软件切分成许多部分单独开发,然后再组装起来,每一个部分即为模块。当使用模块化开发的时候可以避免刚刚的问题,并且让开发的效率变高,以及方便后期的维护。
这是最原始的 JavaScript 文件加载方式,如果把每一个文件看做是一个模块,那么他们的接口通常是暴露在全局作用域下,也就是定义在 window 对象中。
缺点:
1.污染全局作用域
2.只能按script标签书写顺序加载
3.文件依赖关系靠开发者主观解决
允许模块通过require方法来同步加载(同步意味阻塞)所要依赖的其他模块,然后通过module.exports来导出需要暴露的接口。
// module add.js
module.exports = function add (a, b) { return a + b; }
// main.js
var {add} = require('./math');
console.log('1 + 2 = ' + add(1,2);
CommonJS 是以在浏览器环境之外构建JavaScript 生态系统为目标而产生的项目,比如在服务器和桌面环境中。
(1)AMD
AMD 是 RequireJS 在推广过程中对模块定义的规范化产出(异步模块定义)。
AMD标准中定义了以下两个API:
require接口用来加载一系列模块,define接口用来定义并暴露一个模块。
define(['./a', './b'], function(a, b) {
// 依赖必须一开始就写好
a.add1()
...
b.add2()
...
})
优点:
1、适合在浏览器环境中异步加载模块 2、可以并行加载多个模块
(2)CMD
CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。(在CommomJS和AMD基础上提出)
define(function (requie, exports, module) {
//依赖可以就近书写
var a = require('./a');
a.add1();
...
if (status) {
var b = requie('./b');
b.add2();
}
});
优点:
1、依赖就近,延迟执行 2、可以很容易在服务器中运行
(3)AMD 和 CMD 的区别
AMD和CMD起来很相似,但是还是有一些细微的差别:
1、对于依赖的模块,AMD是提前执行,CMD是延迟执行。
2、AMD推崇依赖前置;CMD推崇依赖就近,只有在用到某个模块的时候再去require。
3、AMD 的 API 默认是一个当多个用,CMD 的 API 严格区分,推崇职责单一
EcmaScript6 标准增加了JavaScript语言层面的模块体系定义。
在 ES6 中,我们使用export关键字来导出模块,使用import关键字引用模块。
// module math.jsx
export default class Math extends React.Component{}
// main.js
import Math from "./Math";
目前很少JS引擎能直接支持 ES6 标准,因此 Babel 的做法实际上是将不被支持的import翻译成目前已被支持的require。
可以直接在任何变量或者函数前面加上一个 export
关键字,就可以将它导出。
这种写法非常简洁,和平时几乎没有区别,唯一的区别就是在需要导出的地方加上一个 export 关键字。
比如:
export const sqrt = Math.sqrt;
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}
然后在另一个文件中这样引用:
import { square, diag } from 'lib';
console.log(square(11)); // 121
console.log(diag(4, 3));
你可能会注意到这个奇怪的语法 { square, diag }
不就是前面讲过的 destructing吗。所以你会以为还可以这样写:
import lib from 'lib';
square = lib.square;
但是其实这样是错的,因为 import { square, diag } from 'lib’;
是import的特有语法,并不是 destructing 语法,所以其实import的时候并不是直接把整个模块以对象的形式引入的。
如果你希望能通过 lib.square
的形式来写,你应该这样导入:
import * as lib from 'lib';
square = lib.square;
不过值得注意的一点是,如果你直接用babel编译,执行是会报错的。因为 babel 并不会完全编译 modules,他只是把 ES6 的modules语法编译成了 CMD 的语法,所以还需要用 browserify 之类的工具再次编译一遍。
如果你发现 browserify 找不到 lib
,可以改成 from ‘./lib’
试试。
大家会发现上面的写法比较麻烦,因为必须要指定一个名字。其实很多时候一个模块只导出了一个变量,根本没必要指定一个名字。
还有一种用法叫默认导出,就是指定一个变量作为默认值导出:
//------ myFunc.js ------
export default function () { ... };
//------ main1.js ------
import myFunc from 'myFunc';
myFunc();
默认导出的时候不需要指定一个变量名,它默认就是文件名。
这里的区别不仅仅是不用写名字,而是 导出的默认值就是模块本身,而不是模块下面的一个属性,即是 import myFunc from 'myFunc’;
而不是 import {myFunc} from 'myFunc’;
默认导出同样可以结合命名导出来使用:
export default function (obj) {
...
};
export function each(obj, iterator, context) {
...
}
export { each as forEach };
上面的代码导出了一个默认的函数,然后由导出了两个命名函数,我们可以这样导入:
import _, { each } from 'underscore';
注意这个逗号语法,分割了默认导出和命名导出
其实这个默认导出只是一个特殊的名字叫 default,你也可以就直接用他的名字,把它当做命名导出来用,下面两种写法是等价的:
import { default as foo } from 'lib';
import foo from 'lib';
同样的,你也可以通过显示指定 default
名字来做默认导出, 下面两种写法是一样的:
//------ module1.js ------
export default 123;
//------ module2.js ------
const D = 123;
export { D as default };
ES6规范只支持静态的导入和导出,也就是必须要在编译时就能确定,在运行时才能确定的是不行的,比如下面的代码就是不对的:
//动态导入
var mylib;
if (Math.random()) {
mylib = require('foo');
} else {
mylib = require('bar');
}
//动态导出
if (Math.random()) {
exports.baz = ...;
}
为什么要这么做,主要是两点:
总结一下,ES6提供了如下几种导入方式:
// Default exports and named exports
import theDefault, { named1, named2 } from 'src/mylib';
import theDefault from 'src/mylib';
import { named1, named2 } from 'src/mylib';
// Renaming: import named1 as myNamed1
import { named1 as myNamed1, named2 } from 'src/mylib';
// Importing the module as an object
// (with one property per named export)
import * as mylib from 'src/mylib';
// Only load the module, don’t import anything
import 'src/mylib';
如下几种导出方式:
//命名导出
export var myVar1 = ...;
export let myVar2 = ...;
export const MY_CONST = ...;
export function myFunc() {
...
}
export function* myGeneratorFunc() {
...
}
export class MyClass {
...
}
// default 导出
export default 123;
export default function (x) {
return x
};
export default x => x;
export default class {
constructor(x, y) {
this.x = x;
this.y = y;
}
};
//也可以自己列出所有导出内容
const MY_CONST = ...;
function myFunc() {
...
}
export { MY_CONST, myFunc };
//或者在导出的时候给他们改个名字
export { MY_CONST as THE_CONST, myFunc as theFunc };
//还可以导出从其他地方导入的模块
export * from 'src/other_module';
export { foo, bar } from 'src/other_module';
export { foo as myFoo, bar } from 'src/other_module';
webpack并不强制你使用某种模块化方案,而是通过兼容所有模块化方案让你无痛接入项目。有了webpack,你可以随意选择你喜欢的模块化方案,至于怎么处理模块之间的依赖关系及如何按需打包,webpack会帮你处理好的。
关于模块化的一些内容,可以看看我之前的文章:js的模块化进程
把所有依赖打包成一个bundle.js文件,通过代码分割成单元片段并按需加载。
如图,entry.js是入口文件,调用了util1.js和util2.js,而util1.js又调用了util2.js。
打包后的bundle.js例子
/******/ ([
/* 0 */ //模块id
/***/ function(module, exports, __webpack_require__) {
__webpack_require__(1); //require资源文件id
__webpack_require__(2);
/***/ },
/* 1 */
/***/ function(module, exports, __webpack_require__) {
//util1.js文件
__webpack_require__(2);
var util1=1;
exports.util1=util1;
/***/ },
/* 2 */
/***/ function(module, exports) {
//util2.js文件
var util2=1;
exports.util2=util2;
/***/ }
...
...
/******/ ]);
_webpack_require__(1)
表示 util1.js 模块,__webpack_require__(2)
表示 util2.js 模块exports.util1=util1
模块化的体现,输出该模块