前端模塊化開發(fā)的價值

隨著互聯(lián)網(wǎng)的飛速發(fā)展，前端開發(fā)越來越復雜。本文將從實際項目中遇到的問題出發(fā)，講述模塊化能解決哪些問題，以及如何使用 SeaJS 進行前端的模塊化開發(fā)。

惱人的命名沖突

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

function each(arr) {  
  // 實現(xiàn)代碼  
}  
function log(str) {  
  // 實現(xiàn)代碼  
} 

并像模像樣地把這些函數(shù)統(tǒng)一放在 util.js 里。需要用到時，引入該文件就行。這一切工作得很好，同事也很感激我提供了這么便利的工具包。

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

抱怨越來越多。團隊經(jīng)過一番激烈的討論，決定參照 Java 的方式，引入命名空間來解決。于是 util.js 里的代碼變成了

var org = {};  
org.CoolSite = {};  
org.CoolSite.Utils = {};  
 
org.CoolSite.Utils.each = function (arr) {  
  // 實現(xiàn)代碼  
};  
 
org.CoolSite.Utils.log = function (str) {  
  // 實現(xiàn)代碼  
};  

不要認為上面的代碼是為了寫這篇文章而故意捏造的。將命名空間的概念在前端中發(fā)揚光大，首推 Yahoo! 的 YUI2 項目。下面是一段真實代碼，來自 Yahoo! 的一個開源項目。

if (org.cometd.Utils.isString(response)) {  
  return org.cometd.JSON.fromJSON(response);  
}  
if (org.cometd.Utils.isArray(response)) {  
  return response;  
}  

通過命名空間，的確能極大緩解沖突。但每每看到上面的代碼，都忍不住充滿同情。為了調(diào)用一個簡單的方法，需要記住如此長的命名空間，這增加了記憶負擔，同時剝奪了不少編碼的樂趣。

作為前端業(yè)界的標桿，YUI 團隊下定決心解決這一問題。在 YUI3 項目中，引入了一種新的命名空間機制。

YUI().use('node', function (Y) {  
  // Node 模塊已加載好  
  // 下面可以通過 Y 來調(diào)用  
  var foo = Y.one('#foo');  
});  

YUI3 通過沙箱機制，很好的解決了命名空間過長的問題。然而，也帶來了新問題。

YUI().use('a', 'b', function (Y) {  
  Y.foo();  
  // foo 方法究竟是模塊 a 還是 b 提供的？  
  // 如果模塊 a 和 b 都提供 foo 方法，如何避免沖突？  
});  

看似簡單的命名沖突，實際解決起來并不簡單。如何更優(yōu)雅地解決？我們按下暫且不表，先來看另一個常見問題。

煩瑣的文件依賴

繼續(xù)上面的故事。基于 util.js，我開始開發(fā) UI 層通用組件，這樣項目組同事就不用重復造輪子了。

其中有一個最被大家喜歡的組件是 dialog.js，使用方式很簡單。

<script src="util.js"></script>  
<script src="dialog.js"></script>  
<script>  
  org.CoolSite.Dialog.init({ /* 傳入配置 */ });  
</script>  

可是無論我怎么寫文檔，以及多么鄭重地發(fā)郵件宣告，時不時總會有同事來詢問為什么 dialog.js 有問題。通過一番排查，發(fā)現(xiàn)導致錯誤的原因經(jīng)常是

<script src="dialog.js"></script>  
<script>  
  org.CoolSite.Dialog.init({ /* 傳入配置 */ });  
</script>  

在 dialog.js 前沒有引入 util.js，因此 dialog.js 無法正常工作。同樣不要以為我上面的故事是虛構(gòu)的，在我待過的公司里，至今依舊有類似的腳本報錯，特別是在各種快速制作的營銷頁面中。

上面的文件依賴還在可控范圍內(nèi)。當項目越來越復雜，眾多文件之間的依賴經(jīng)常會讓人抓狂。下面這些問題，我相信每天都在真實地發(fā)生著。

1.通用組更新了前端基礎(chǔ)類庫，卻很難推動全站升級。

2.業(yè)務組想用某個新的通用組件，但發(fā)現(xiàn)無法簡單通過幾行代碼搞定。

3.一個老產(chǎn)品要上新功能，最后評估只能基于老的類庫繼續(xù)開發(fā)。

4.公司整合業(yè)務，某兩個產(chǎn)品線要合并。結(jié)果發(fā)現(xiàn)前端代碼沖突。

5.……

以上很多問題都是因為文件依賴沒有很好的管理起來。在前端頁面里，大部分腳本的依賴目前依舊是通過人肉的方式保證。當團隊比較小時，這不會有什么問題。當團隊越來越大，公司業(yè)務越來越復雜后，依賴問題如果不解決，就會成為大問題。

文件的依賴，目前在絕大部分類庫框架里，比如國外的 YUI3 框架、國內(nèi)的 KISSY 等類庫，目前是通過配置的方式來解決。

YUI.add('my-module', function (Y) {  
  // ...  
}, '0.0.1', {  
    requires: ['node', 'event']  
});  

上面的代碼，通過 requires 等方式來指定當前模塊的依賴。這很大程度上可以解決依賴問題，但不夠優(yōu)雅。當模塊很多，依賴很復雜時，煩瑣的配置會帶來不少隱患。

命名沖突和文件依賴，是前端開發(fā)過程中的兩個經(jīng)典問題。下來我們看如何通過模塊化開發(fā)來解決。為了方便描述，我們使用 SeaJS 來作為模塊化開發(fā)框架。

使用 SeaJS 來解決

SeaJS 是一個成熟的開源項目，核心目標是給前端開發(fā)提供簡單、極致的模塊化開發(fā)體驗。這里不多做介紹，有興趣的可以訪問 seajs.org 查看官方文檔。

使用 SeaJS，在書寫文件時，需要遵守 CMD （Common Module Definition）模塊定義規(guī)范。一個文件就是一個模塊。前面例子中的 util.js 變成

define(function(require, exports) {  
  exports.each = function (arr) {  
    // 實現(xiàn)代碼  
  };  
 
  exports.log = function (str) {  
    // 實現(xiàn)代碼  
  };  
});  

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

define(function(require, exports) {  
  var util = require('./util.js');  
 
  exports.init = function() {  
    // 實現(xiàn)代碼  
  };  
});  

關(guān)鍵部分到了！我們通過 require('./util.js') 就可以拿到 util.js 中通過 exports 暴露的接口。這里的 require 可以認為是 SeaJS 給 JavaScript 語言增加的一個 **語法關(guān)鍵字*8，通過 require 可以獲取其他模塊提供的接口。

這其實一點也不神奇。作為前端工程師，對 CSS 代碼一定也不陌生。

@import url("base.css");  
 
#id { ... }  
.class { ... }  

SeaJS 增加的 require 語法關(guān)鍵字，就如 CSS 文件中的 @import 一樣，給我們的源碼賦予了依賴引入功能。

如果你是后端開發(fā)工程師，更不會陌生。Java、Python、C# 等等語言，都有 include、import 等功能。JavaScript 語言本身也有類似功能，但目前還處于草案階段，需要等到 ES6 標準得到主流瀏覽器支持后才能使用。

這樣，在頁面中使用 dialog.js 將變得非常簡單。

<script src="sea.js"></script>  
<script>  
seajs.use('dialog', function(Dialog) {  
  Dialog.init(/* 傳入配置 */);  
});  
</script>  

首先要在頁面中引入 sea.js 文件，這一般通過頁頭全局把控，也方便更新維護。想在頁面中使用某個組件時，只要通過 seajs.use 方法調(diào)用。

好好琢磨以上代碼，我相信你已經(jīng)看到了 SeaJS 帶來的兩大好處。

1.通過 exports 暴露接口。這意味著不需要命名空間了，更不需要全局變量。這是一種徹底的命名沖突解決方案。

2.通過 require 引入依賴。這可以讓依賴內(nèi)置，開發(fā)者只需關(guān)心當前模塊的依賴，其他事情 SeaJS 都會自動處理好。對模塊開發(fā)者來說，這是一種很好的 關(guān)注度分離，能讓程序員更多地享受編碼的樂趣。

小結(jié)

除了解決命名沖突和依賴管理，使用 SeaJS 進行模塊化開發(fā)還可以帶來很多好處：

1.模塊的版本管理。通過別名等配置，配合構(gòu)建工具，可以比較輕松地實現(xiàn)模塊的版本管理。

2.提高可維護性。模塊化可以讓每個文件的職責單一，非常有利于代碼的維護。SeaJS 還提供了 nocache、debug 等插件，擁有在線調(diào)試等功能，能比較明顯地提升效率。

3.前端性能優(yōu)化。SeaJS 通過異步加載模塊，這對頁面性能非常有益。SeaJS 還提供了 combo、flush 等插件，配合服務端，可以很好地對頁面性能進行調(diào)優(yōu)。

4.跨環(huán)境共享模塊。CMD 模塊定義規(guī)范與 Node.js 的模塊規(guī)范非常相近。通過 SeaJS 的 Node.js 版本，可以很方便實現(xiàn)模塊的跨服務器和瀏覽器共享。

模塊化開發(fā)并不是新鮮事物，但在 Web 領(lǐng)域，前端開發(fā)是新生崗位，一直處于比較原始的刀耕火種時代。直到最近兩三年，隨著 Dojo、YUI3、Node.js 等社區(qū)的推廣和流行，前端的模塊化開發(fā)理念才逐步深入人心。

前端的模塊化構(gòu)建可分為兩大類。一類是以 Dojo、YUI3、國內(nèi)的 KISSY 等類庫為代表的大教堂模式。在大教堂模式下，所有組件都是顆粒化、模塊化的，各組件之間層層分級、環(huán)環(huán)相扣。另一類是以 jQuery、RequireJS、國內(nèi)的 SeaJS、OzJS 等類庫為基礎(chǔ)的集市模式。在集市模式下，所有組件彼此獨立、職責單一，各組件通過組合松耦合在一起，協(xié)同完成開發(fā)。

這兩類模塊化構(gòu)建方式各有應用場景。從長遠來看，小而美更具備寬容性和競爭力，更能形成有活力的生態(tài)圈。

總之，模塊化能給前端開發(fā)帶來很多好處。如果你還沒有嘗試，不妨從試用 SeaJS 開始。

原文鏈接：https://github.com/seajs/seajs/issues/547