探索可獨立開發和橫向擴展的微前端模塊化方案

關於前端模塊化

• 說到前端模塊化，你立刻想到的可能就是 cmd、amd、umd 等前端模塊化標準，這些是屬於文件級別的模塊化；
• 或者你會想到 component 的封裝、npm 包的封裝等等，這些屬於組件級別的模塊化；
• 或者你會想到將頁面切割成不少獨立的區塊，每一個區塊是一個模塊，這些屬於視圖級別的模塊化；
• 而今天要探討的是的業務功能級別前端模塊化。

業務功能級別前端模塊化在後臺開發人員眼中再熟悉不過了，咱們一般說的"用戶模塊","訂單模塊","評論模塊"等都是從業務功能視角來劃分的。隨着前端承載的功能愈來愈厚重，如今已經不僅是簡單渲染一個視圖而已，它每每也包含不少的業務邏輯和狀態，因此愈來愈多的前端工程中也出現了 model、controller、states 等概念，若是前端模塊化僅僅停留在文件、組件級別，那麼整個工程將變得難以維護和拓展。

業務模塊應當是高內聚、低耦合的總體封裝

看了不少時下流行的前端工程結構，每每是這樣：

├── src
│   ├── assets
│   ├── components
│   ├── layouts
│   ├── models //vuex或者dva，按業務功能劃分模塊
│   │     ├── user
│   │     ├── order
│   │     └── comment
│   ├── pages
│   ├── services
│   ├── utils

能夠看到，在 models(store)這個領域，仍是有按照業務功能劃分了模塊，可是...也僅限於 models 而已，脫離 view，單純一個 model 模塊有什麼意義？這樣的模塊化完整嗎？能獨立開發嗎？能靈活插拔嗎？能橫向擴展嗎？

一個完整的模塊應當包含：

• 一個 model 處理抽象邏輯和狀態
• 一組相關的 views，用來展現 model。注意：model 和 view 是一對多的關係
• 一些其它 components 和輔助資源

它們應當集中歸類到一個目錄下面，而不是零碎的分散在各個角落，獨立開發的時候我只須要擁有這個目錄的修改權限而不是整個工程，插拔模塊的時候只須要 copy 或 del 這個目錄，而不是翻出各個目錄去查找相關文件...

因此我指望的工程結構應當是這樣：

├── src
│   ├── assets      //公用資源
│   ├── components  //公用組件
│   ├── utils       //公用工具
│   ├── modules     //多個獨立的業務模塊
│   │     │
│   │     ├── user  //用戶模塊
│   │     │    ├── assets      //私用資源
│   │     │    ├── components  //私用組件
│   │     │    ├── utils  //私用工具
│   │     │    ├── model  //model
│   │     │    └── views  //一個或多個視圖
│   │     │          ├── page1
│   │     │          ├── page2
│   │     │          ├── list
│   │     │          ├── editor
│   │     │          └── layout
│   │     │
│   │     ├── order //訂單模塊
│   │     │    ├── assets      //私用資源
│   │     │    ├── components  //私用組件
│   │     │    ├── utils  //私用工具
│   │     │    ├── model  //model
│   │     │    └── views  //一個或多個視圖
│   │     │          ├── page1
│   │     │          ├── page2
│   │     │          ├── list
│   │     │          ├── editor
│   │     │          └── layout
│   │     │
│   │     ├── comment //評論模塊
│   │     │    ├── ...

能夠看到每一個 module 都有一套獨立的目錄結構，各類資源都被區分爲公用資源 和 模塊私有資源，全部模塊僅依賴公用資源，模塊與模塊之間切割得十分乾淨了。

視圖的模塊化

把 page(view)也歸類到不一樣到模塊，你可能會問：若是一個 view 裏面包含了多個模塊到內容，那這個 view 應當屬於哪一個模塊呢？這種狀況下，咱們須要對該 view 進行切割，讓其變成多個功能更單一的子 view，view 是能夠嵌套的不是嗎？

按需組合與加載

當某客戶但願購買一個"文章模塊「，固然是圍繞文章模塊相關的代碼和資源一併打包給他，單獨給他一個 view 或者 model 是毫無心義的，那樣也跑不起來。

按需加載也是同樣：按需加載的應當是整個模塊，而不是傳統意義上的懶加載某個 component

因此，工程化打包的時候，應當把整個模塊文件夾下全部代碼打包成一個獨立的 bundle，包括 views、model、components 和其它輔助代碼。

注意對外封裝

模塊是按照「高內聚、低耦合」的原則劃分的，模塊與模塊之間是鬆散的，大量的方法和接口應當封裝在模塊內部，僅按需對外暴露和導出。若是 2 個模塊之間聯繫特別緊密，那是否要考慮一下它們是否是要合併成一個模塊

關於微前端

從幾什麼時候前端也開始思考和借鑑後端「微服務」的概念，但願能找到一種方案讓複雜的前端業務也能應用自治，可是目前來講這是一種美好的想法，具體怎麼落地尚沒有成熟案例，而儘量的內聚、隔離模塊之間的關係卻是理念共識。

個人解決方案

上面只是思考與思路，實現這個思路固然有各類具體的方案，好比我原創的：medux 系列框架，歡迎探討:

• 歡迎試用跨平臺前端框架@medux
• 結合案例：medux-react-admin