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

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

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

缺點:

1、污染全局作用域

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

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

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

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

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

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

優(yōu)點：

1、簡單并容易使用

2、服務(wù)器端模塊便于重用

缺點:

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

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

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

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

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

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

exports示例：

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

module.exports示例：

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

錯誤的情況：

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

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

總結(jié)：當我們想讓模塊導(dǎo)出的是一個對象時， exports 和 module.exports 均可使用（但 exports 也不能重新覆蓋為一個新的對象），而當我們想導(dǎo)出非對象接口時，就必須也只能覆蓋 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。看代碼：

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

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

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

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

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

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

示例：

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

優(yōu)點：

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

2、面向未來的 EcmaScript 標準

缺點：

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

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

以上就是本文的全部內(nèi)容，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，同時也希望多多支持武林網(wǎng)！