演示地址
https://chjtx.com/wanxiang/app1
倉庫地址
https://gitee.com/chenjianlong/wanxiang
前言
-
如何理解微前端？獨立部署，無感加載，環境隔離？
-
微前端能解決什麼問題？不影響老系統前提下開發新業務享受新技術帶來的便利？拆分系統分散到各開發小組方便維護？
-
目前主流微前端框架 qiankun 是否滿足上述所有訴求？
在嘗試過用 vite 搭建 qiankun 項目後，我發現幾個問題：
-
1、開發環境下主應用訪問不到子應用，即使網上有很多方案，但始終還是做不到 js 沙箱和 css 樣式絕對隔離
-
2、微應用切換時依然是加載所有資源，並不會比刷新頁面加載的資源少
既然加載的資源不會比刷新頁面少，那麼我們可不可以直接刷新頁面呢？只要首屏資源足夠輕量，響應速度足夠快，同樣可以達到無感切換。我參與過不少用 webpack 搭建的 qiankun 項目，幾乎所有項目都是主應用加載菜單，子應用業務內容在右側主體區域顯示的模式。那麼換個思路，所以業務應用都優先加載菜單，通過本地緩存記錄菜單數據、狀態甚至滾動位置，是否就可以達到無感刷新切換應用的效果？而用這種傳統的刷新頁面方式根本不用考慮 js 、css 被其它應用污染的問題。
對比
| 方案 | 乾坤 | 萬象 |
|---|---|---|
| 運行方式 | 攔截子應用代碼，經過轉換再掛載到主應用 | 沒有主子應用之分，只有簡單的加載公共菜單 |
| 沙箱隔離 | 支持 js、css 沙隔離，但 js 通過 with 限制作用域，css 通過自動添加前綴，轉換過程中有性能損耗 | 天然隔離，無須各種轉換，切換應用直接刷新頁面，不存在性能損耗 |
| 子應用 | 支持 | 不支持 |
| 更新部署 | 只有主應用更新時，無須更新子應用 | 公共菜單更新時，需要更新所有應用 |
| 複雜度 | 主子應用使用相同技術棧比較容易上手，使用不同技術棧樣式隔離比較頭疼 | 爲了保障菜單加載速度，達到無感刷新效果，使用純原生技術開發，對維護菜單的開發者技術要求較高 |
| 掌控度 | 遇到bug需要向社區反饋，等待解決方案，自行修改源碼難度較高 | 整體就一個菜單組件的代碼量，完全可以自行修改源碼 |
| 成熟度 | 螞蟻內部服務了超過 2000+ 線上應用 | 新鮮出爐，還沒遇到什麼坑，理論上應該沒什麼坑 |
目錄結構
--/
|-- common/ # 公共組件模塊
|-- wanxiang/
|-- app1/ # 應用1，獨立倉庫
|-- package.json
|-- app2/ # 應用2，獨立倉庫
|-- package.json
|-- package.json
|-- .gitignore # 忽略掉 app1 和 app2
如上圖目錄結構，有3個git倉庫，一個公共的，一個 app1，一個 app2
app1 和 app2 都可以通過配置依賴路徑別名加載 common 的資源，樸素無華，沒有花裏胡哨的模塊聯邦。
多倉庫模式能有效解決開發團隊的權限問題，同時避免了 git 歷史記錄洪流。
開始
<!-- index.html -->
<head></head>
<body>
<div id="app"></div>
<!-- 將 main.js 替換爲 entry.js -->
<script src="entry.js"></script>
</body>
// enrty.js
import { start, setMenus } from 'common/wanxiang/index.js'
start(`#app`, () => {
// 關鍵點，顯示完主體菜單再加載業務代碼
import('./main.js')
// 加載菜單數據
fetch('/menu').then(res => res.json()).then(res => {
setMenus(res.data)
})
})
後語
萬象不是框架也不是插件，是一種方案，一種管理大規模前端應用的方案，沒有具體的標準，根據各自項目需求對公共菜單進行調整，因此每個項目都會有不同的表象，遂取名爲“萬象”。