模塊化在項目中十分的重要，一個復雜的項目肯定有很多相似的功能模塊，如果每次都需要重新編寫模塊肯定既費時又耗力。但是引用別人編寫模塊的前提是要有統(tǒng)一的“打開姿勢”，如果每個人有各自的寫法，那么肯定會亂套，下面介紹幾種JS的模塊化的規(guī)范。

一:模塊化進程一：script標簽

這是最原始的 JavaScript 文件加載方式，如果把每一個文件看做是一個模塊，那么他們的接口通常是暴露在全局作用域下，也就是定義在 window 對象中，不同模塊的接口調用都是一個作用域中，一些復雜的框架，會使用命名空間的概念來組織這些模塊的接口。

缺點:

1、污染全局作用域

2、開發(fā)人員必須主觀解決模塊和代碼庫的依賴關系

3、文件只能按照script標簽的書寫順序進行加載

4、在大型項目中各種資源難以管理，長期積累的問題導致代碼庫混亂不堪

二:模塊化進程二：CommonJS規(guī)范

該規(guī)范的核心思想是允許模塊通過require方法來同步加載所要依賴的其他模塊，然后通過 exports 或 module.exports 來導出需要暴露的接口。

require("module");
require("../file.js");
exports.doStuff = function(){};
module.exports = someValue;

優(yōu)點：

1、簡單并容易使用

2、服務器端模塊便于重用

缺點:

1、同步的模塊加載方式不適合在瀏覽器環(huán)境中，同步意味著阻塞加載，瀏覽器資源是異步加載的

2、不能非阻塞的并行加載多個模塊

module.exports與exports的區(qū)別

1、exports 是指向的 module.exports 的引用

2、module.exports 初始值為一個空對象 {}，所以 exports 初始值也是 {}

3、require() 返回的是 module.exports 而不是 exports

exports示例：

// app.js
var circle = require('./circle');
console.log(circle.area(4));
// circle.js
exports.area = function(r){
 return r * r * Math.PI;
}

module.exports示例：

// app.js
var area = require('./area');
console.log(area(4));
// area.js
module.exports = function(r){
 return r * r * Math.PI;
}

錯誤的情況：

// app.js
var area = require('./area');
console.log(area(4));
// area.js
exports = function(r){
 return r * r * Math.PI;
}

其實是對 exports 進行了覆蓋，也就是說 exports 指向了一塊新的內存（內容為一個計算圓面積的函數(shù)），也就是說 exports 和 module.exports 不再指向同一塊內存，也就是說此時 exports 和 module.exports 毫無聯(lián)系，也就是說 module.exports 指向的那塊內存并沒有做任何改變，仍然為一個空對象{}，也就是說area.js導出了一個空對象，所以我們在 app.js 中調用 area(4) 會報 TypeError: object is not a function 的錯誤。

總結：當我們想讓模塊導出的是一個對象時， exports 和 module.exports 均可使用（但 exports 也不能重新覆蓋為一個新的對象），而當我們想導出非對象接口時，就必須也只能覆蓋 module.exports 。

三:模塊化進程三：AMD規(guī)范

由于瀏覽器端的模塊不能采用同步的方式加載，會影響后續(xù)模塊的加載執(zhí)行，因此AMD(Asynchronous Module Definition異步模塊定義)規(guī)范誕生了。

AMD標準中定義了以下兩個API

1、require([module], callback);
2、define(id, [depends], callback);

require接口用來加載一系列模塊，define接口用來定義并暴露一個模塊。

示例：

define("module", ["dep1", "dep2"], function(d1, d2){
 return someExportedValue;
});
require(["module", "../file"], function(module, file){ /* ... */ });

優(yōu)點：

1、適合在瀏覽器環(huán)境中異步加載模塊

2、可以并行加載多個模塊

缺點：

1、提高了開發(fā)成本，代碼的閱讀和書寫比較困難，模塊定義方式的語義不順暢

2、不符合通用的模塊化思維方式，是一種妥協(xié)的實現(xiàn)

四:模塊化進程四：CMD規(guī)范

CMD(Common Module Definition)規(guī)范和AMD很相似，盡量保持簡單，并與CommonJS和Node.js的 Modules 規(guī)范保持了很大的兼容性。在CMD規(guī)范中，一個模塊就是一個文件。

示例：

define(function(require, exports, module){
 var $ = require('jquery');
 var Spinning = require('./spinning');
 exports.doSomething = ...
 module.exports = ...
})

優(yōu)點：

1、依賴就近，延遲執(zhí)行

2、可以很容易在 Node.js 中運行

缺點：

1、依賴 SPM 打包，模塊的加載邏輯偏重

AMD和CMD的區(qū)別

AMD和CMD起來很相似，但是還是有一些細微的差別，讓我們來看一下他們的區(qū)別在哪里：

1、對于依賴的模塊，AMD是提前執(zhí)行，CMD是延遲執(zhí)行。

2、AMD推崇依賴前置；CMD推崇依賴就近，只有在用到某個模塊的時候再去require。看代碼：

// AMD
define(['./a', './b'], function(a, b){ // 依賴必須一開始就寫好
  a.doSomething()  
  // 此處略去 100 行
  b.doSomething()  
  ...
});
// CMD
define(function(require, exports, module){
  var a = require('./a')  
  a.doSomething()  
  // 此處略去 100 行
  var b = require('./b')
  // 依賴可以就近書寫
  b.doSomething()
  // ...
});

3、AMD 的 API 默認是一個當多個用，CMD 的 API 嚴格區(qū)分，推崇職責單一。

五:模塊化進程五：ES6模塊化

EcmaScript6標準增加了JavaScript語言層面的模塊體系定義。ES6 模塊的設計思想，是盡量的靜態(tài)化，使得編譯時就能確定模塊的依賴關系，以及輸入和輸出的變量。CommonJS和AMD模塊，都只能在運行時確定這些東西。

在 ES6 中，我們使用export關鍵字來導出模塊，使用import關鍵字引用模塊。需要說明的是，ES6的這套標準和目前的標準沒有直接關系，目前也很少有JS引擎能直接支持。因此Babel的做法實際上是將不被支持的import翻譯成目前已被支持的require。

盡管目前使用import和require的區(qū)別不大(本質上是一回事)，但依然強烈推薦使用import關鍵字，因為一旦JS引擎能夠解析ES6的import關鍵字，整個實現(xiàn)方式就會和目前發(fā)生比較大的變化。如果目前就開始使用import關鍵字，將來代碼的改動會非常小。

示例：

import "jquery";
export functiondoStuff(){}
module "localModule" {}

優(yōu)點：

1、容易進行靜態(tài)分析

2、面向未來的 EcmaScript 標準

缺點：

1、原生瀏覽器端還沒有實現(xiàn)該標準

2、全新的命令字，新版的 Node.js才支持

以上就是本文的全部內容，希望本文的內容對大家的學習或者工作能帶來一定的幫助，同時也希望多多支持腳本之家！

最新評論