大家好，我是Eluxjs的作者，Eluxjs是一套基于“微模塊”和“模型驅動”的跨平臺、跨框架『同構方案』，歡迎了解...
文前宣告，以下推斷和結論純屬個人探索，鑒于本人知識水平所限，謬誤在所難免，懇請各位大佬不吝賜教...
什么是前端“微模塊”？
Elux中的『微模塊』是指在Web前端工程中，將代碼和相關資源按照不同的業務功能進行歸類和模塊化，
根據業務功能進行模塊化一直以來都是后端的普遍做法，而Web前端則通常都是按照UI界面的視圖區塊View來進行模塊化，這樣的模塊實際上只是Component組件，不具備獨立自治的能力，究其原因我想是因為在早期Web1.0的時代，前端的職能就是僅僅作為后端API資料的一個Render渲染器，所以前后端的視野和格局出現了分化，也導致很多人說前端根本無架構之說，
然而web生態發展到今天，瀏覽器越來越強大，賦能越來越多，甚至不亞于一個小型作業系統，這時候的Web前端早已不是當初簡單的資料渲染器，狀態管理、會話維持、資料持久化、檔案快取、通信協議...隨著PWA、小程式、快應用的推廣，WebAPP不再是瘦客戶端，漸漸成長為大胖小子，
此時的我們應當跳出“渲染器”的井口，而從一個完整的軟體工程來思考我們的前端架構，Web前端不只是一層View、一個GUI，我們需要回歸到與后端一致的以業務領域為驅動的模塊化視角，
為什么前端需要“微模塊”？
-
從開發角度來說：我們需要
高內聚、低耦合的松散結構體，而不是牽一發而動全身的巨石應用，這不管是對于開發、維護、還是后期漸進式重構，都至關重要，前端Leader：經過一年多的迭代和人員變動，我們代碼已經混亂不堪了，開發越來越吃力，必須要重構，否則玩不下去了！ 產品經理：嗯，我理解，這里面也有很多是我們需求變更頻繁引起的，我支持你們重構！ 前端Leader：感謝大佬理解，那新需求先停下來，等我們重構好了再迭代吧？ 產品經理：你們重構要多久？ 前端Leader：產品這么復雜了，估計至少要3個月左右吧， 產品經理被嚇出一身冷汗：大佬，你要3天還可以考慮，停下來3個月估計公司都要關門了... 前端Leader：可是產品這么復雜，幾天時間完成重構是天方夜譚， 產品經理想了想：這樣把，我每個迭代少安排幾個需求，這樣你們每個月就可以留幾天時間重構了， 前端Leader：這可不是1+1=2的問題，而是0與1的問題，大佬你不了解！ 產品經理：誰說我不了解，你們就不能漸進式重構嗎？ 前端Leader：...此時如果我們的前端工程是基于“微模塊”，一來可以輕松的找到“區域重構”的
邊界，二來也可以通過維持“微模塊”的對外介面來無極替換， -
從產品角度來說：軟體架構永遠是服務于業務需求的，我們希望我們的產品能像搭積木一樣
按需組合，可以快速包裝出各種靈活多樣的套餐，以滿足客戶越來越精細化的定制需求，某個大型應用包含A,B,C,D,E,F,G等若干功能，原來一直是整體打包出售... 隨著用戶需求的多樣化，有的用戶僅需要部分功能，于是聰明的前端架構師“小李”利用時下流行的微前端技術， 將應用拆分成了的 3 個子應用： - 【基礎應用】包含功能：A - 【子應用A】包含功能：B,C,D - 【子應用B】包含功能：E,F,G 這樣等于有 3 個套餐可以供客戶選擇： - 套餐A：基礎應用 + 子應用A - 套餐B：基礎應用 + 子應用B - 套餐C：基礎應用 + 子應用A + 子應用B 然而用戶的需求越來越精細化，有的需要ABCD，有的需要ACEG，有的需要ABDF... 而且同一個功能可能還存在需求版本的不同，這讓“小李”無可適從，現在我們利用“微模塊”來幫助小李解決問題：
- 將各種獨立的業務功能封裝成不同的微模塊：A,B,C,D,E,F,G
- 將各種微模塊按需求迭代版本，發布成NPM包
- 某客戶需要 A,C1(
C功能的某個版本),E2(E功能的某個版本),G 功能，我們單獨為該客戶創建一個聚合工程分支，安裝相應版本的微模塊：npm install A C@1 E@2 G
我們知道世界上有一款建站神器
wordpress，曾經號稱世界上50%的網站都是由它創建的，我認為它的成功秘訣就是社區模版機制和功能插件化，你要什么功能都總能找到“前端+后端”一起打包安裝的插件，這也類似于“微模塊”的概念，
- 從工程的角度來說：“微模塊”是跨工程、跨專案共享
通用業務代碼的理想決方案，對于跨端、跨平臺復用業務邏輯尤其有用，
前端“微模塊”的劃分原則與邊界
- 擁有
高內聚、低耦合的工程結構， - 擁有
獨立自治的子域邏輯，
從圖中可以看到，每個微模塊負責定義和維護自己領域內的事務，并且麻雀雖小，五臟俱全，擁有獨立的路由決議、狀態管理、資料模型、控制器、視圖、組件、資源、業務物體、API管理等等...總之，所有與自己領域相關的資源都被內聚到了一起，
以下是某巨石應用的SRC目錄，其特點是以“檔案職能”作為一級分類、“功能模塊”作為次級分類：
├─ src
│ ├─ api # API介面管理
│ ├─ assets # 靜態資源檔案
│ ├─ components # 全域組件
│ ├─ config # 全域配置項
│ ├─ enums # 專案列舉
│ ├─ hooks # 常用 Hooks
│ ├─ language # 語言國際化
│ ├─ layout # 框架布局
│ ├─ routers # 路由管理
│ ├─ store # store
│ ├─ styles # 全域樣式
│ ├─ typings # 全域 ts 宣告
│ ├─ utils # 工具庫
│ ├─ views # 專案所有頁面
│ ├─ App.vue # 入口頁面
│ └─ main.ts # 入口檔案
以下是Elux中基于微模塊的SRC目錄，其改進是將“功能模塊”作為一級分類，“檔案職能”作為次級分類：
src
├── modules
│ ├── ModuleA
│ │ ├── entities
│ │ ├── assets
│ │ ├── api
│ │ ├── utils
│ │ ├── language
│ │ ├── components
│ │ ├── views
│ │ ├── model.ts
│ │ └── index.ts
│ │
│ ├── ModuleB
│ ├── ModuleC
微模塊的臺前與幕后
前端開發最終呈現的是UI界面，但這只是表象，支撐UI界面渲染和互動的是背后一系列state、model、controller等幕后英雄，它們根據自己所屬不同領域被封裝在各個微模塊中，UI既然與它們唇齒相依，必然也將跟隨它們內聚在一起，
View和Component
本質上說View就是一個Component，但我們從架構的思維來區分它們：
- View：業務視圖，它用來表現業務規則與邏輯，通常能夠較為獨立和完整的解決某一領域問題，
- Component：UI組件，它用來表現渲染規則與互動邏輯，通常不與具體業務直接相關，可復用在各種不同業務場景中，
所以在“微模塊”的架構中，豐富多彩的UI界面由一個個單一職責的View聚合而成，每個View同樣依據自身所解決的領域問題而被分散在各個微模塊中，這里面有幾個注意點：
- 領域性：View被歸屬到不同
微模塊的原則是其解決的問題領域，而不是視覺上的幾何空間，View可以在視覺上被拆裝、聚合、嵌套，這并不影響它們所屬微模塊， - 完整性：一個View通常能解決一個較為獨立和完整的問題，View與View之間是較為松散的關系，如果2個View之間聯系緊密，那就不應當拆分它們，
不以視覺延伸和幾何空間作為View的微模塊歸屬原則：如下圖所示，假設有一個View用來展示用戶資料，我們將其放在UserModule這個微模塊中，稱其為UserModule.DetailView，但你發現其中又包含一個該用戶發表文章的串列，你當然可以把這個串列單獨提取出來作為一個新的View，從視覺上來看，它似乎和用戶資料是連在一起的，似乎可以和UserModule.DetailView放在同一個微模塊中；但我們從它解決的問題來看，它屬于文章領域，而與用戶領域關系并不大，所以我們最好將其放在ArticleModule中，稱其為ArticleModule.ListView
前端“微模塊”的實作方案
- 定義和創建微模塊，可借助于Eluxjs框架，當然你發現了其它框架也可以，
- 管理微模塊，可借助于NPM倉庫，
- 使用微模塊，可借助于打包工具：
- 靜態編譯：微模塊作為一個NPM包被安裝到工程中，通過打包工具（如webpack）正常編譯打包即可，這種方式的優點是代碼產物得到打包工具的各種去重和優化；缺點是當某個模塊更新時，需要整體重新打包，
- 動態注入：利用
Module Federation，將微模塊作為子應用獨立部署，與時下流行的微前端類似，這種方式的優點是某子應用中的微模塊更新時，依賴該微模塊的其它應用無需重新編譯，重繪瀏覽器即可動態獲取最新模塊；缺點是沒有打包工具的整體編譯與優化，代碼和資源容易重復加載或沖突，
微模塊 vs 微前端
從本意上來說，微模塊只是一種工程結構和模塊化方案，而微前端只是它的一種應用場景之一，微模塊架構不僅可以用來構建復雜的單體應用，也可以結合Module Federation實作多子應用獨立部署的“微前端”，
如果單獨就微模塊 + ModuleFederation方式實作的微前端，與傳統意義上的qiankun、icestark等微前端方案相比，微模塊方式勝在粒度更細、更靈活、更輕巧，而傳統方式則勝在隔離性更好，
想到一個非常形象的比喻：
IFrame vs 微前端 vs 微模塊 可類比于 行程 vs 執行緒 vs 協程
從左至右：越來越輕量化，隔離性逐漸變弱，靈活性逐漸增加，所以魚與熊掌不可兼得，具體哪種方案最適合還得看不同的產品需求，
微模塊之間的通信
- 微模塊之間按照某些規則和約定共享同一個Runtime，強制隔離性較弱，所以它們之間的通信是輕量級的，可以相互參考與呼叫，
- 建議觀察者模式，或者使用事件總線模式來保持微模塊之間的松散關系，這是另一個故事，可參考Eluxjs中的
ActionBus， - 微模塊
高內聚、低耦合的劃分原則，也意味著微模塊之間不會出現特別復雜的互動與交流（互動密切的微模塊應當合并），
落地與實戰
光練不說傻把式，光說不練假把式，這里先把思路概念要說的說完，下面就要開始出實體了，先喝口水，請聽下回分解...????急性子也可以直接去Eluxjs官網，看看Demo，不吝賜教...
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/502661.html
標籤：其他
上一篇：小米商城購物車案例實作