淺談JS前端模塊化的幾種規范

Posted on by

前言

有這樣一個場景，客戶端運行很久，但是法務部和數據部需要收集用戶的一些信息，這些信息收集好之後需要進行相應的數據處理，之後上報到服務端。客戶端提供一個純粹的js執行引擎，不需要 WebView 容器。iOS 端有成熟的JavaScriptCore、Android 可以使用 V8 引擎。這樣一個引擎配套有一個 SDK，訪問 Native 的基礎能力和數據運算能力，可以看成是一個閹割版的 Hybrid SDK 額外增加瞭一些數據處理能力。

問題結束瞭嗎？處理邏輯的時候還需要用到2個庫：cheerio和sql。因為都是 Node 工程，所以純粹的js環境是沒辦法直接執行。所以需求就進行瞭轉變 ———— 將 Node 項目打包成 UMD 規范。這樣就可以在純粹的 JS 環境下運行。接下來的文章就分析下各種規范。其實也就是前端模塊化的幾種規范。

前端模塊化開發的價值

隨著互聯網的飛速發展，前端開發越來越復雜。本文將從實際項目中遇到的問題出發，講述模塊化能解決哪些問題，以及以 Sea.js 為例講解如何進行前端的模塊化開發。

惱人的命名沖突

我們從一個簡單的習慣出發。我做項目時，常常會將一些通用的、底層的功能抽象出來，獨立成一個個函數，比如

function  each(arr) {
// 實現代碼
} 

function  log(str) {
// 實現代碼
}

並像模像樣的將這些代碼抽取出來並統一到util.js中，在需要使用的地方引入該文件，看起來很棒，團隊內的同事很感激我提供瞭這麼便利的工具包。

直到團隊越來越大，開始有人抱怨

小楊：我定義瞭一個 each 方法遍歷對象，但是 util.js 中已經存在一個 each 方法，每次都需要改方法名，我隻能叫 eachObject 方法。<br>張三：我定義瞭一個 log 方法，可是王武的代碼出問題瞭，誰來看看？

抱怨越來越多，最後參照 Java 的方式，引入命名空間解決問題。於是 util.js 代碼變成瞭

var  org = {};

org.Utils = {};

org.Utils.each = function (arr) {

// 實現代碼

};

org.Utils.log = function (str) {

// 實現代碼

};

可能看上去的代碼很 low，其實命名空間在前端領域的佈道者是 Yahoo！的 YUI2 項目，看看下面的代碼，是 Yahoo！的一個開源項目

if (org.cometd.Utils.isString(response)) {

return  org.cometd.JSON.fromJSON(response);

}

if (org.cometd.Utils.isArray(response)) {

return  response;

}

通過命名空間雖然可以極大的解決沖突問題，但是每次在調用一個方法時都需要寫一大堆命名空間相關的代碼，剝奪瞭編碼樂趣。

另一種方式是一個自執行函數來實現。

(function (args) {

//...

})(this);

繁瑣的文件依賴

繼續上述場景，很多情況下都需要開發 UI 層通用組件，這樣項目組就不需要重復造輪子。其中有一個高頻使用的組件就是 dialog.js

<script  src="util.js"></script>

<script  src="dialog.js"></script>

<script>

org.Dialog.init({  /* 傳入配置 */  });

</script>

雖然公共組做項目都會編寫使用文檔、發送郵件告知全員（項目地址、使用方式等），但是還是有人問「為什麼 dialog.js 有問題」，最後排查的結果基本都是沒有引入 util.js

<script  src="dialog.js"></script>

<script>

org.Dialog.init({  /* 傳入配置 */  });

</script>

命名沖突和文件依賴是前端開發中2個經典問題，經過開發者不斷的思考和研究，誕生瞭模塊化的解決方案，以 CMD 為例

define(function(require, exports) {

exports.each = function (array) {

// ...

};

exports.log = function(message) {

// ...

};

});

通過 exports 就可以向外提供接口， dialog.js 代碼變成

define(function(require, exports) {

var  util = require('./util.js')

  

exports.init = function () {

// ...

};

});

使用的時候可以通過require(‘./util.js’)獲取到 util.js 中通過 exports 暴露的接口。 require 的方式在其他很多語言中都有解決方案：include、

模塊化的好處

1.模塊的版本管理：通過別名等配置，配合構建工具，可以輕松實現模塊的版本管理

2.提高可維護性： 模塊化可以實現每個文件的職責單一，非常有利於代碼的維護。

3.前端性能優化： 對於前端開發來說，異步加載模塊對於頁面性能非常有益。

4.跨環境共享模塊： CMD 模塊定義規范與 NodeJS 的模塊規范非常相近，所以通過 Sea.JS 的 NodeJS 版本，可以方便的實現模塊的跨服務器和瀏覽器共享。

CommonJS 規范

CommonJS 是服務器端模塊的規范。NodeJS 采用瞭這個規范。CommonJS 加載模塊是同步的，所以隻有加載完成後才能執行後面的操作。

因為服務器的特點，加載的模塊文件一般都存在在本地硬盤，所以加載起來比較快，不用考慮異步的方式。

CommonJS 模塊化的餓規范中，每個文件都是一個模塊，擁有獨立的作用域、變量、以及方法等，對其他模塊不可見。 CommonJS 規范規定，每個模塊內部，module變量表示當前模塊，它是一個對象，它的exports屬性是對外的接口，加載某個模塊，其實是加載該模塊的 module.exports 屬性，require 方法用於加載模塊。

// Person.js

function  Person () {

this.eat = function () {

console.log('eat something')

}

  

this.sleep = function () {

console.log('sleep')

}

}

  

var  person = new  Person();

exports.person = person;

exports.name = name;

  

// index.js

let  person = require('./Person').person;

person.eat()

CommonJS 與 ES6 模塊的差異

1.CommonJS 模塊輸出的是值的拷貝，ES6 模塊輸出的是值的引用

2.CommonJS 模塊是運行時加載，ES6 模塊是編譯時輸出接口

CommonJS 模塊導出的是一個對象（module.exports 屬性），該對象隻在腳本運行完才會生成。

ES6 的模塊機制是 JS 引擎對腳本進行靜態分析的時候，遇到模塊加載命令 import，就會生成一個隻讀引用，等到腳本真正執行時，再根據這個隻讀引用到被加載的模塊中取值，

AMD 規范

AMD（Asynchronous Module Definition） 是在 Require.JS 推廣的過程中對模塊定義的規范化產出。AMD 推崇依賴前置。它是 CommonJS 模塊化規范的超集，作用在瀏覽器上。它的特點是異步，利用瞭瀏覽器的並發能力，讓模塊的依賴阻塞變少。

AMD 的 API

define(id?, dependencyies?, factory);

id 是模塊的名字，是可選參數。 dependencies 指定瞭該模塊所依賴的模塊列表，是一個數組，也是可選參數。每個依賴的模塊的輸出都將作為參數依次傳入 factory 中。

require([module], callback)

AMD 規范允許輸出模塊兼容 CommonJS 規范，這時 define 方法如下

define(['module1', 'module2'], function(module1, module2) {

function  foo () {

// ...

}

return { foo:  foo };

});


define(function(require, exports, module) {

var  requestedModule1 = require('./module1')

var  requestedModule2 = require('./module2')

function  foo () {

// ...

}

return { foo:  foo };

});

優點： 適合在瀏覽器環境中加載模塊，可以實現並行加載多個模塊

缺點： 提高瞭開發成本，並不能按需加載，而是提前加載所有的依賴

CMD 規范

CMD 是 Sea.JS 推廣的過程中對模塊定義的規范化產出。CMD 推崇依賴就近。

CMD 規范盡量保持簡單，並與 CommonJS 規范中的 Module 保持兼容，通過 CMD 規范編寫的模塊，可以在 NodeJS 中運行。

CMD 模塊定義規范

CMD 中 require 依賴的描述用數組，則是異步加載，如果是單個依賴使用字符串，則是同步加載。

AMD 是 RequireJS 在推廣過程中對模塊定義的規范化產出，CMD是SeaJS 在推廣過程中被廣泛認知。SeaJS 出自國內螞蟻金服玉伯。二者的區別，玉伯在12年如是說：

RequireJS 和 SeaJS 都是很不錯的模塊加載器，兩者區別如下：

  • 兩者定位有差異。RequireJS 想成為瀏覽器端的模塊加載器，同時也想成為 Rhino / Node 等環境的模塊加載器。SeaJS 則專註於 Web 瀏覽器端，同時通過 Node 擴展的方式可以很方便跑在 Node 服務器端
  • 兩者遵循的標準有差異。RequireJS 遵循的是 AMD（異步模塊定義）規范，SeaJS 遵循的是 CMD （通用模塊定義）規范。規范的不同，導致瞭兩者API 的不同。SeaJS 更簡潔優雅，更貼近 CommonJS Modules/1.1 和 Node Modules 規范。
  • 兩者社區理念有差異。RequireJS 在嘗試讓第三方類庫修改自身來支持 RequireJS，目前隻有少數社區采納。SeaJS 不強推，而采用自主封裝的方式來“海納百川”，目前已有較成熟的封裝策略。
  • 兩者代碼質量有差異。RequireJS 是沒有明顯的 bug，SeaJS 是明顯沒有 bug。
  • 兩者對調試等的支持有差異。SeaJS 通過插件，可以實現 Fiddler 中自動映射的功能，還可以實現自動 combo 等功能，非常方便便捷。RequireJS無這方面的支持。
  • 兩者的插件機制有差異。RequireJS 采取的是在源碼中預留接口的形式，源碼中留有為插件而寫的代碼。SeaJS 采取的插件機制則與 Node 的方式一致開放自身，讓插件開發者可直接訪問或修改，從而非常靈活，可以實現各種類型的插件。

UMD 規范

UMD（Universal Module Definition）是隨著大前端的趨勢產生，希望提供一個前後端跨平臺的解決方案（支持 AMD、CMD、CommonJS 模塊方式）。

實現原理：

1.先判斷是否支持 Node.js 模塊格式（exports 是否存在），存在則使用 Node.js 模塊格式

2.再判斷是否支持 AMD 模塊格式（define 是否存在），存在則使用 AMD 模塊格式

3.前2個都不存在則將模塊公開到全局（window 或 global）

// if the module has no dependencies, the above pattern can be simplified to

(function (root, factory) {

if (typeof  define === 'function' && define.amd) {

// AMD. Register as an anonymous module.

define([], factory);

} else  if (typeof  exports === 'object') {

// Node. Does not work with strict CommonJS, but

// only CommonJS-like environments that support module.exports,

// like Node.

module.exports = factory();

} else {

// Browser globals (root is window)

root.returnExports = factory();

}

}(this, function () {

  

// Just return a value to define the module export.

// This example returns an object, but the module

// can return a function as the exported value.

return {};

}));

可能有些人就要問瞭，為什麼在上面的判斷中寫瞭 AMD，怎麼沒有 CMD？因為前端構建工具webpack不可識別 CMD 規范，使用 CMD 就需要引用工具，比如 Sea.JS

講道理，如果想判斷 CMD，那 UMD 代碼如何寫？

(function(root, factory) {

if (typeof  define === 'function' && define.amd) {

// AMD. Register as an anonymous module.

define([], factory);

} else  if (typeof  define === 'function' && define.cmd) {

// CMD

define(function(require, exports, module) {

module.exports = factory()

})

} else  if (typeof  exports === 'object') {

// Node. Does not work with strict CommonJS, but

// only CommonJS-like environments that support module.exports,

// like Node.

module.exports = factory();

} else {

// Browser globals (root is window)

root.returnExports = factory();

}

}(this, function() {

// Just return a value to define the module export.

// This example returns an object, but the module

// can return a function as the exported value.

return {};

}))

回到正題

Cheerio 如何打包到普通的 JS 執行環境中。

借助webpack可以方便的打出一個 umd 規范的包。

module.exports = {

entry:  './src/cheerio.js',

output: {

filename:  'cheerio.js',

// export to AMD, CommonJS, or window

libraryTarget:  'umd',

// the name exported to window

library:  'cheerio',

globalObject:  'this'

}

}

總結

手機端（無論 iOS 還是 Android）的底層渲染內核都是類 Chrome v8 引擎。v8 引擎在執行 JS 代碼時，是將代碼先以 MacroAssembler 匯編庫在內存中先編譯成機器碼再送往 CPU 執行的，並不是像其它 JS 引擎那樣解析一行執行一行。所以，靜態加載的 ES6 模塊規范，更有助於 v8 引擎發揮價值。而運行時加載的 CommonJS、AMD、CMD 規范等，均不利於 v8 引擎施展拳腳。

在 NodeJS 開發項目中，Node9 已經支持 ES6語法，完全可以使用 ES6 模塊規范。NodeJS 的誕生，本身就基於 Google 的 v8 引擎，沒有理由不考慮發揮 v8 的最大潛能。

在瀏覽器 JS 開發項目中，因為從服務器加載文件需要時間，使用 CommonJS 規范肯定是不合適瞭。至於是使用原生的 ES 模塊規范，還是使用 Sea.js，要看具體場景。如果想頁面盡快加載，Sea.js 適合；如果是單頁面網站，適合使用原生的 ES6 模塊規范。還有一點，瀏覽器並非隻有 Chrome 一傢，對於沒有使用 v8 引擎的瀏覽器，使用 ES6 原生規范的優勢就又減少瞭一點。

以上就是淺談JS前端模塊化的幾種規范的詳細內容，更多關於JS前端模塊化的資料請關註WalkonNet其它相關文章！

推薦閱讀：