這篇文章分享的不是成功的經驗，而是失敗的教訓~

設坑

關於為什麼要研究元件化以及之前對元件化實現方式的理解都在這篇文章——《利用handlebars實現後端元件化》。本來按照之前的思路，覺得元件化應該有三種實現方式，一種是後端模板；一種是瀏覽器端由js實現，包括reactjs的元件、angular的指令等，不過這些對css檔案無法管理（有個外掛號稱完美實現元件化，研究完之後再分析）；最後一種就是利用構建工具實現元件化。

如果真能找到這樣一種構建工具，不依賴前後端語言、模板、框架，在構建程式碼的時候直接直接將元件打包是不是很完美？如果你也這麼想，那麼恭喜你可以跟我一其踏上一段踩坑之旅了。

入坑

目標已經明確的話開始尋找工具。理想的是有工具外掛直接實現元件化，差一點的話自己稍加改造實現也可以接受。看看現在比較流行的工程化工具：

webpack

首先研究這個最新最火的工具，一進入官網就被那個炫酷的css3立方體吸引了，看上去很高大上的樣子。官網上內容很多，雖然是英文的但是問題不大。看到選單上有一系列教程（list of tutorials）非常欣喜，心想好軟體就是不一樣，教程都寫得這麼多。一點開傻眼了，根本就不是什麼學習教程，就是各種語言湊起來的文章，完全無法引導新手很好的學習，也沒有分類。照著例子使用了之後發現如其所說只是個模組打包工具，恨不能讓任何頁面只引用一個js一個css，對第三方依賴的處理也是狗血，要麼合併成一個，要麼一個一個配置，手動在html中維護，而且還是侵入式的改變原始碼內容。功能很簡單，實現過程很複雜，蛋疼之後更是伴隨一陣心疼，遂放棄。
如有不對之處，歡迎webpack資深玩家拍磚指點。

fis3

其實從fis剛出來的時候我就在關注fis，那時候因為覺得外掛不夠豐富，再加上專案中使用的是grunt，所以放棄了。這次看到fis的教學視訊和fis3的時候我是內心有些激動的。一方面見其生機勃勃，另一方面介紹了百度產品實現元件化的經驗。
事情真的那麼完美嗎？首先不得不承認fis3是一個比較成熟的構建工具，但是一上手就坑了我，release釋出程式碼的時候不能清除目錄，只能覆蓋釋出，號稱400多個外掛中也沒找到可以實現的，我只能用一個字形容——囧。這種感覺就像你來到了一棟摩天大樓，但是它沒有電梯，你只能自己爬上去。再細緻研究發現其元件化也是依賴後端語言實現的，和後端模板整合在一起，做事情做一半，真是無語。至於Angular和Angular2這種靠前端模板的例子也不是我要找的答案。
不過其目錄劃分可能還有一些借鑑意義吧。

現坑

gulp

gulp和grunt功能上差不多，豐富的擴充套件性決定了其能成為最強大的前端構建工具。gulp效率高一些，所以這裡只討論gulp。當不停地尋找合適外掛的時候終於發現一個關鍵性的功能似乎不能實現，那就是元件的巢狀引用以及依賴資源的自動合併，如果需要實現這個功能那麼要動態處理html程式碼識別資源然後進行整合，這個功能是不是有些熟悉，對，這就是之前寫過的利用後端模板引擎做的事情。
想到這裡，這個坑就明顯了：我在試圖用構建工具來侵入程式碼來完成模板引擎該做的工作而同時它還無法像模板引擎一樣填充資料。這就好比我在用羽毛球拍打乒乓球，還一直覺得是球拍品牌不夠好所以打不好球。

出坑

回過頭來看看構建工具的職能到底是什麼？
fis3給其定義了三大職能

• 資源定位：獲取任何開發中所使用資源的線上路徑；
• 內容嵌入：把一個檔案的內容(文字)或者 base64 編碼(圖片)嵌入到另一個檔案中；
• 依賴宣告：在一個文字檔案內標記對其他資源的依賴關係；——很可惜這個任務沒有完全完成
  這三大職能看似很完美，但實際上都是需要在修改原始碼的基礎上實現，這種耦合程度就很不友好。一方面造成程式碼混亂，另一方面如果要替換構建工具也變得不可能。
  再看gulp/grunt這種自動化構建工具，將壓縮、編譯、單元測試、lint等重複性工作自動化，不要求改變原始碼，我覺得這種無耦合的方式才通用更利於維護。
  總之，如果編寫fis3外掛來自動處理依賴宣告的話，利用構建工具來實現元件化應該是可以的。只是在前後端分離、行為結構樣式分離的今天來做這樣一件事顯然不是最佳最友好的實現方式~

打賞支援我寫出更多好文章，謝謝！

打賞作者