關於微前端的技術思考
目前微前端的概念已經火了一段時間了，社群也有相對來說比較出名的解決方案，如single-spa、qiankun等。但是關於本篇文章將拋開框架來談一下對於微前端的思考。
微前端的優點
微前端為什麼能火，當然有其優點，比較突出的主要有以下幾點： 1. 技術棧無關（很多專案由於歷史包袱等原因可能技術棧比較老） 2. 獨立開發、獨立部署（一些大型的專案，動輒幾十上百個頁面，每次開發跑起來都要很久，同時也可能存在node記憶體不足的問題。同時，獨立的環境能比較業務模組間的互相影響） 3. 各業務模組獨立，便於升級和重構等
微前端的難點
微前端有其特點，但是其在技術實現上也有一定的技術難點。本人在內部自研的微前端解決方案實現的過程中也遇到了一些相關的問題。
路由切換
微前端給使用者感知其實仍然是接近於單頁面應用的，微前端的路由仍然可以採用單頁面應用的路由導航方案，這一點相對來說比較容易解決。我在實現自己的解決方案時直接借用了vue-router的能力，有興趣的也可以直接看一下相關的框架的路由實現或去了解一下瀏覽器的history api
子應用掛載
應用掛載的本質上還是在html上新增子應用的css和js。這裡的實現思路主要是監測路由的變化，在路由變化的同時開始掛載子應用的資源。
在實踐中，我也是通過監聽路由，同時將各個子應用的資源存在對應的變數中，當進入應用是，直接將對應的資源掛載，這裡在實現過程中是和路由切換一起實現的。
子應用的通訊
由於各個子應用間是相互獨立的，所以一些資料並不能共享，但我們的業務是不可能完全分割的，所以需要進行應用間的通訊。這裡我們可以使用幾種方法
1. 藉助框架的實現，例如可以藉助vue或者vuex，利用它們來實現一個簡單的Event Bus進行通訊，這裡相信的可以看vuex的原始碼，不再贅述
2. 使用瀏覽器本身事件機制，通過事件的監聽和傳遞來實現，具體api是的CustomEvent
css隔離
css隔離主要有幾種方法
1. css樣式的新增和移除。可以通過主應用的指令碼來監測子應用的掛載和銷燬，同時對css樣式進行新增和移除。但這裡有一個要注意的點就是要對子應用的打包進行改造，獲取打包後的css樣式地址
2. 使用scope-css。開發過程中不設定全域性樣式，全部使用scope-css，全域性樣式存放在主應用。這種方式相對比較簡單
3. 對子應用的樣式全部新增字首，這個和方式2原理相似，可以藉助使用postcss來實現
4. 使用shadow DOM。這個方式存在相容性問題，同時如果要做樣式穿透比較麻煩，有興趣可以瞭解一下，我感覺它的功能不止這些。官方文件
js隔離
js隔離相對來說比較麻煩，因為即使你移除了js，但是其執行後的影響仍然存在，比如全域性變數的汙染、定時器等問題。好在現在很多專案基本都是基於webpack構建，全域性變數較少，處理起來也相對簡單，同時在子應用開發的過程中及時清理定時任務即可。
在實踐的過程中，主要是在主應用定義可預測的全域性變數，同時，實現了一個快照的功能，對應用的執行時狀態儲存，當子應用銷燬時，根據快照恢復應用狀態即可。但這個仍然不是完全的沙箱，還是存在js互相影響的可能。期待社群有更好的解決方案。
寫在最後
微前端我的理解是現在並沒有什麼最好的解決方案，他是一種思想，一種解耦的思想，而不是具體到某個框架。其實只要符合你的業務需求，同時利用好微前端的優點即可。比如我在實踐的過程中，也是藉助vue的一些能力去進行微前端的實現，雖然目前存在些許不足，但減少了對原有程式碼的改造，同時學習成本也較低，這也是我比較滿意的地方，