關于前端模塊化
- 說到前端模塊化，你馬上想到的可能就是 cmd、amd、umd 等前端模塊化標準，這些是屬于檔案級別的模塊化；
- 或者你會想到 component 的封裝、npm 包的封裝等等，這些屬于組件級別的模塊化；
- 或者你會想到將頁面切割成很多獨立的區塊，每個區塊是一個模塊，這些屬于視圖級別的模塊化；
- 而今天要探討的是的業務功能級別前端模塊化。
業務功能級別前端模塊化在后臺開發人員眼中再熟悉不過了，我們通常說的"用戶模塊","訂單模塊","評論模塊"等都是從業務功能視角來劃分的。隨著前端承載的功能越來越厚重，現在已經不只是簡單渲染一個視圖而已，它往往也包含很多的業務邏輯和狀態，所以越來越多的前端工程中也出現了 model、controller、states 等概念，如果前端模塊化僅僅停留在檔案、組件級別，那么整個工程將變得難以維護和拓展。
業務模塊應當是高內聚、低耦合的整體封裝
看了很多時下流行的前端工程結構，往往是這樣：
可以看到，在 models(store)這個領域，還是有按照業務功能劃分了模塊，但是...也僅限于 models 而已，脫離 view，單純一個 model 模塊有什么意義？這樣的模塊化完整嗎？能獨立開發嗎？能靈活插拔嗎？能橫向擴展嗎？
它們應當集中歸類到一個目錄下面，而不是零碎的分散在各個角落，獨立開發的時候我只需要擁有這個目錄的修改權限而不是整個工程，插拔模塊的時候只需要 copy 或 del 這個目錄，而不是翻出各個目錄去查找相關檔案...
所以我期望的工程結構應當是這樣：
可以看到每個 module 都有一套獨立的目錄結構，各種資源都被區分為公用資源 和 模塊私有資源，所有模塊僅依賴公用資源，模塊與模塊之間切割得十分干凈了。
視圖的模塊化
把 page(view)也歸類到不同到模塊，你可能會問：如果一個 view 里面包含了多個模塊到內容，那這個 view 應當屬于哪個模塊呢？這種情況下，我們需要對該 view 進行切割，讓其變成多個功能更單一的子 view，view 是可以嵌套的不是嗎？
按需組合與加載
當某客戶希望購買一個"文章模塊“，當然是圍繞文章模塊相關的代碼和資源一并打包給他，單獨給他一個 view 或者 model 是毫無意義的，那樣也跑不起來。
按需加載也是一樣：按需加載的應當是整個模塊，而不是傳統意義上的懶加載某個 component
所以，工程化打包的時候，應當把整個模塊檔案夾下所有代碼打包成一個獨立的 bundle，包括 views、model、components 和其它輔助代碼。
注意對外封裝
模塊是按照“高內聚、低耦合”的原則劃分的，模塊與模塊之間是松散的，大量的方法和介面應當封裝在模塊內部，僅按需對外暴露和匯出。如果 2 個模塊之間聯系特別緊密，那是否要考慮一下它們是不是要合并成一個模塊
我的解決方案
上面只是思考與思路，實作這個思路當然有各種具體的方案，比如我原創的：medux 系列框架，歡迎探討:
歡迎試用跨平臺前端框架@medux
結合實際案例：medux-react-admin
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/32105.html
標籤：JavaScript