前端模块化开发简介
历史上，JavaScript 一直没有模块（module）体系，无法将一个大程序拆分成互相依赖的小文件，再用简单的方法拼装起来。其他语言都有这项功能，比如 Ruby 的require、Python 的import，甚至就连 CSS 都有@import，但是 JavaScript 任何这方面的支持都没有，这对开发大型的、复杂的项目形成了巨大障碍。
开始之前
我们先用几个问题, 探讨下, 在没有模块化的情况下, 我们如何解决这些问题
Q1
如何解决JS全局变量/函数冲突?
A1
自执行函数
// b.js
var a = 1;
// a.js
(function(args){
var a = 2;
console.log(a); // 2
console.log(window.a); // 1
}).call(context,args);
Q2
依赖顺序&&重复引入问题
-
a.js 依赖 b.js 如何保证顺序?
-
a.js, b.js 都依赖 c.js, 如何保c不被重复引入?
A2
-
检查
<head>标签,确保依赖顺序 -
将所有文件按依赖顺序合并
Q3
按需加载问题
- 如果只使用某个库的其中一个功能, 不得不把整个库引入
A3
手动分离所需代码
模块化所解决的问题
- 模块作用域: 安全的包装一个模块的代码--不污染模块外的任何代码
- 模块唯一性: 唯一标识一个模块--避免重复引入
- 模块的导出: 优雅的把模块的API暴漏给外部--不增加全局变量
- 模块的引入: 方便的使用所依赖的模块
目前模块化的解决方案
- CommonJS -- Node.js
- AMD -- RequireJS
- CMD -- SeaJS
- UMD
- ES6 Module
CommonJS
- 一个单独的JS文件就是一个模块,每一个模块都是一个单独的作用域
- 定义全局函数require，通过传入模块标识来引入其他模块，执行的结果即为别的模块暴漏出来的API
- 如果被require函数引入的模块中也包含依赖，那么依次加载这些依赖
- 如果引入模块失败，那么require函数应该报一个异常
- 模块通过变量exports来向外暴漏API，exports只能是一个对象，暴漏的API须作为此对象的属性。
CommonJS 例子
//a.js
exports.foo = function() {
console.log('foo')
}
//b.js
var a = require('./a.js')
a.foo()
CommonJS 缺点
- 只能在服务端(Node.js)使用, 不能在浏览器直接使用
- 模块是同步加载的, 如果加载过慢会阻塞进程
AMD(Asyncchronous Module Definition)
- 专门为浏览器量身定制,兼容IE6+(在node.js中使用适配器也可以用)
- 模块是异步加载的
- 用全局函数define来定义模块，用法为：
define(id?, dependencies?, factory)- 使用全局函数require来引入模块, 用法为:
require(dependencies?, callback)
AMD 例子
//a.js
define(function(){
return {
hello: function(){
console.log('hello, a.js')
}
}
})
// main.js
require(['a', 'other'], function(a, other){
a.hello() // hello, a.js
other.foo()
})
AMD缺点
- 预下载, 预解释, 带来额外性能消耗
- 书写复杂
- 回调地狱
define(['a', 'b', 'c', 'd', 'e', 'f', 'g'], function(a, b, c, d, e, f, g){ })
AMD演示
AMD演示:目录结构
source_tree.png
AMD演示:主页文件/project.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Page Title</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<script data-main="scripts/main"src="scripts/require.js"></script>
</head>
<body>
</body>
</html>
AMD演示:JS入口文件/scripts/main.js
requirejs(["helper/util"], function(util) {
if(!condition){
util.foo()
}
});
AMD演示:模块/scripts/helper/util.js
define(function(require, factory) {
'use strict';
return {
foo: function(){
console.log("hello util.js");
}
};
});
AMD演示:运行结果
console.png
network.png
CMD(Common Module Definition)
SeaJS
SeaJS集各家所长, 融合了太多的东西，已经无法说它遵循哪个规范了，所以干脆就自立门户，起名曰CMD（Common Module Definition）规范
比较
- AMD推崇(但不强制)依赖前置，在定义模块的时候就要用
require声明其依赖的 - CMD推崇(但不强制)就近依赖，只有在用到某个模块的时候再去
require - CMD不需要AMD那样的回调写法, 可以像CommonJS一样的同步写法(但加载其实还是异步的)
- AMD模块是提前执行的, 而CMD模块默认是延迟执行的
- 由于延迟加载, CMD用户体验稍差
UMD(Universal Module Definition)
同时兼容AMD, CommonJS的模块化定义
-
写法丑陋复杂, 但是能够支持多种规范
(function (root, factory) { if (typeof define === 'function' && define.amd) { define(['jquery'], factory); // AMD } else if (typeof exports === 'object') { module.exports = factory(require('jquery'));// CommonJS } else { root.returnExports = factory(root.jQuery); // 浏览器全局变量 } }(this, function ($) { function foo(){$()}; return foo; }));
ES6 Module -- 面向未来的模块标准
ES6 在语言标准的层面上，实现了模块功能，而且实现得相当简单，完全可以取代 CommonJS 和 AMD 规范，成为浏览器和服务器通用的模块解决方案
- 但是到目前为止, 浏览器对ES6 Module的支持还是相当不完善
ES6 模块的设计思想，是尽量的静态化，使得编译时就能确定模块的依赖关系，从而进行一些优化。CommonJS 和 AMD 模块，都只能在运行时确定依赖
- 在ES8的stage-3提案中, 出现了
动态import即import()方法,它返回一个Promise对象, 允许动态导入模块
ES6 Module 基本用法
-
定义模块
//变量, module.js export var bar = 'bar' // 函数, module.js export function foo(){} // 统一导出&重命名, module.js var bar = 'bar' function foo(){} export { bar as myBar, foo } // 默认导出, module.js function foo(){} export default foo
ES6 Module 基本用法
-
引用模块
// 从模块中导入指定对象, 支持重命名, main.js import { foo, bar as myBar } from './module.js' // 从模块中导入默认对象(名称可跟原名称不一样) import myFoo from './module.js' // 执行模块, 但不导入任何值 import './module.js' // 整体导入 import * as myModule from './module.js' -
注意: ES6 import导入的模块都是原模块的引用
ES6 Module 基本用法
-
浏览器使用: 在入口JS文件加上
type="module"就可以在该文件内使用ES6 Module 语法<script src="scripts/main.js" type="module"></script>
ES6 Module 浏览器支持情况
caniuse.png
总结
| - | 加载机制 | 缺点 | 评价 |
|---|---|---|---|
| CommonJS | 同步加载 | 加载时会阻塞线程,仅适用于后端 | NodeJS首创,具有先导意义 |
| AMD | 异步加载, 依赖前置 | 写法冗余,依赖多的时候很痛苦 | 前端残留势力 |
| CMD | 异步加载, 依赖后知 | 体验略差,需要配合SPM打包工具,配置复杂 | 被创始人说"已死"的规范 |
| UMD | 根据运行环境判断选用合适的方式 | 写法臃肿难看 | 前后端跨平台跨平台的解决方案 |
| ESM | 编译时静态确定 | 浏览器支持乏力,需要配合转译或打包工具使用 | 未来前端模块管理的规范 |
模块化与打包工具
由于模块化方案多样, 且浏览器支持不一, 再加上上述模块化方案仅仅支持JavaScript本身, 对 于复杂的前端应用来说远远不够用, 因此出现了各种打包工具来解决这些问题
-
早期打包工具
- r.js -- RequireJS提供的打包工具,仅仅支持RequireJS
- SPM -- SeaJS提供的打包工具,仅仅支持SeaJS
- browserify -- 让浏览器使用Node.js的NPM模块
- gulp/grunt/fis -- 前端自动化构建, 用来测试,压缩,检错,合并前端代码, 不支持模块化(类似Maven/Gradle)
-
现代打包工具
- webpack -- 高度可配置的静态资源打包器, 有着强大的插件和生态
- rollup -- 小巧高效的前端资源打包器, 适合用来编写库或框架
- parcel -- 后起之秀, 极速零配置Web应用打包工具
webpack 简介
webpack.png
webpack 简介
webpack并不强制你使用某种模块化方案，而是通过兼容所有模块化方案让你无痛接入项目，当然这也是webpack牛逼的地方。 有了webpack，你可以随意选择你喜欢的模块化方案，至于怎么处理模块之间的依赖关系及如何按需打包，webpack会帮你处理好的
webpack 优点
- 可以兼容多模块风格，无痛迁移老项目
- 一切皆模块，js/css/图片/字体/音视频 等都是模块, 都可被打包
- 配合插件/加载器可以进行各种操作: 转译, 代码检查, 压缩等等
- 静态解析，按需打包，动态加载,
- 支持抽离公共模块
- 支持进行代码分隔, 按需下载
- 扩展性强，插件机制强大, 生态完善
- 强大的webpack-dev-server: 检测代码改变, 进行代码热重载, 无需浏览器刷新
网友评论