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

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

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

惱人的命名沖突

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

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

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

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

小楊：我想定義一個 each 方法遍歷對象，但頁頭的 util.js 里已經定義了一個，我的只能叫 eachObject 了，好無奈。

小高：我自定義了一個 log 方法，為什么小明寫的代碼就出問題了呢？誰來幫幫我。

抱怨越來越多。團隊經過一番激烈的討論，決定參照 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;
}

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

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

YUI().use('node', function (Y) {  // Node 模塊已加載好
  // 下面可以通過 Y 來調用
  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)導致錯誤的原因經常是

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

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

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

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

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

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

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

5. ……

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

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

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

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

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

使用 Sea.js 來解決

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

使用 Sea.js，在書寫文件時，需要遵守 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)代碼
  };
});

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

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

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

Sea.js 增加的 require 語法關鍵字，就如 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 方法調用。

好好琢磨以上代碼，我相信你已經看到了 Sea.js 帶來的兩大好處：

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

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

小結

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

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

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

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

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

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

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

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

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

（完）