前端模塊化開發(fā)簡介
歷史上，JavaScript 一直沒有模塊（module）體系，無法將一個大程序拆分成互相依賴的小文件，再用簡單的方法拼裝起來。其他語言都有這項功能，比如 Ruby 的require、Python 的import，甚至就連 CSS 都有@import，但是 JavaScript 任何這方面的支持都沒有，這對開發(fā)大型的、復雜的項目形成了巨大障礙。
開始之前
我們先用幾個問題, 探討下, 在沒有模塊化的情況下, 我們如何解決這些問題
Q1
如何解決JS全局變量/函數(shù)沖突?
A1
自執(zhí)行函數(shù)
// 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
手動分離所需代碼
模塊化所解決的問題
- 模塊作用域: 安全的包裝一個模塊的代碼--不污染模塊外的任何代碼
- 模塊唯一性: 唯一標識一個模塊--避免重復引入
- 模塊的導出: 優(yōu)雅的把模塊的API暴漏給外部--不增加全局變量
- 模塊的引入: 方便的使用所依賴的模塊
目前模塊化的解決方案
- CommonJS -- Node.js
- AMD -- RequireJS
- CMD -- SeaJS
- UMD
- ES6 Module
CommonJS
- 一個單獨的JS文件就是一個模塊,每一個模塊都是一個單獨的作用域
- 定義全局函數(shù)require，通過傳入模塊標識來引入其他模塊，執(zhí)行的結果即為別的模塊暴漏出來的API
- 如果被require函數(shù)引入的模塊中也包含依賴，那么依次加載這些依賴
- 如果引入模塊失敗，那么require函數(shù)應該報一個異常
- 模塊通過變量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中使用適配器也可以用)
- 模塊是異步加載的
- 用全局函數(shù)define來定義模塊，用法為：
define(id?, dependencies?, factory)- 使用全局函數(shù)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集各家所長, 融合了太多的東西，已經無法說它遵循哪個規(guī)范了，所以干脆就自立門戶，起名曰CMD（Common Module Definition）規(guī)范
比較
- AMD推崇(但不強制)依賴前置，在定義模塊的時候就要用
require聲明其依賴的 - CMD推崇(但不強制)就近依賴，只有在用到某個模塊的時候再去
require - CMD不需要AMD那樣的回調寫法, 可以像CommonJS一樣的同步寫法(但加載其實還是異步的)
- AMD模塊是提前執(zhí)行的, 而CMD模塊默認是延遲執(zhí)行的
- 由于延遲加載, CMD用戶體驗稍差
UMD(Universal Module Definition)
同時兼容AMD, CommonJS的模塊化定義
-
寫法丑陋復雜, 但是能夠支持多種規(guī)范
(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 在語言標準的層面上，實現(xiàn)了模塊功能，而且實現(xiàn)得相當簡單，完全可以取代 CommonJS 和 AMD 規(guī)范，成為瀏覽器和服務器通用的模塊解決方案
- 但是到目前為止, 瀏覽器對ES6 Module的支持還是相當不完善
ES6 模塊的設計思想，是盡量的靜態(tài)化，使得編譯時就能確定模塊的依賴關系，從而進行一些優(yōu)化。CommonJS 和 AMD 模塊，都只能在運行時確定依賴
- 在ES8的stage-3提案中, 出現(xiàn)了
動態(tài)import即import()方法,它返回一個Promise對象, 允許動態(tài)導入模塊
ES6 Module 基本用法
-
定義模塊
//變量, module.js export var bar = 'bar' // 函數(shù), module.js export function foo(){} // 統(tǒng)一導出&重命名, 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' // 執(zhí)行模塊, 但不導入任何值 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首創(chuàng),具有先導意義 |
| AMD | 異步加載, 依賴前置 | 寫法冗余,依賴多的時候很痛苦 | 前端殘留勢力 |
| CMD | 異步加載, 依賴后知 | 體驗略差,需要配合SPM打包工具,配置復雜 | 被創(chuàng)始人說"已死"的規(guī)范 |
| UMD | 根據(jù)運行環(huán)境判斷選用合適的方式 | 寫法臃腫難看 | 前后端跨平臺跨平臺的解決方案 |
| ESM | 編譯時靜態(tài)確定 | 瀏覽器支持乏力,需要配合轉譯或打包工具使用 | 未來前端模塊管理的規(guī)范 |
模塊化與打包工具
由于模塊化方案多樣, 且瀏覽器支持不一, 再加上上述模塊化方案僅僅支持JavaScript本身, 對 于復雜的前端應用來說遠遠不夠用, 因此出現(xiàn)了各種打包工具來解決這些問題
-
早期打包工具
- r.js -- RequireJS提供的打包工具,僅僅支持RequireJS
- SPM -- SeaJS提供的打包工具,僅僅支持SeaJS
- browserify -- 讓瀏覽器使用Node.js的NPM模塊
- gulp/grunt/fis -- 前端自動化構建, 用來測試,壓縮,檢錯,合并前端代碼, 不支持模塊化(類似Maven/Gradle)
-
現(xiàn)代打包工具
- webpack -- 高度可配置的靜態(tài)資源打包器, 有著強大的插件和生態(tài)
- rollup -- 小巧高效的前端資源打包器, 適合用來編寫庫或框架
- parcel -- 后起之秀, 極速零配置Web應用打包工具
webpack 簡介
webpack.png
webpack 簡介
webpack并不強制你使用某種模塊化方案，而是通過兼容所有模塊化方案讓你無痛接入項目，當然這也是webpack牛逼的地方。 有了webpack，你可以隨意選擇你喜歡的模塊化方案，至于怎么處理模塊之間的依賴關系及如何按需打包，webpack會幫你處理好的
webpack 優(yōu)點
- 可以兼容多模塊風格，無痛遷移老項目
- 一切皆模塊，js/css/圖片/字體/音視頻 等都是模塊, 都可被打包
- 配合插件/加載器可以進行各種操作: 轉譯, 代碼檢查, 壓縮等等
- 靜態(tài)解析，按需打包，動態(tài)加載,
- 支持抽離公共模塊
- 支持進行代碼分隔, 按需下載
- 擴展性強，插件機制強大, 生態(tài)完善
- 強大的webpack-dev-server: 檢測代碼改變, 進行代碼熱重載, 無需瀏覽器刷新
