本文對微前端的概念和場景進(jìn)行科普，介紹一些主流的微前端的實(shí)現(xiàn)庫及其用法，并講解部分這些庫的原理和實(shí)踐知識。

一、微前端

在項(xiàng)目迭代中，隨著業(yè)務(wù)的發(fā)展壯大，項(xiàng)目的功能模塊通常也會(huì)越來越多?？赡茉瓉硭械拇a模塊都在一個(gè)倉庫里，由一個(gè)團(tuán)隊(duì)負(fù)責(zé)。但隨著功能模塊越來越多，一個(gè)團(tuán)隊(duì)可能負(fù)責(zé)不過來，需要多個(gè)團(tuán)隊(duì)來專門維護(hù)不同的模塊。相應(yīng)的代碼也會(huì)被拆到多個(gè)倉庫里，并且各模塊能獨(dú)立開發(fā)、部署更新。通常雖然項(xiàng)目被拆成了多個(gè)模塊，但為了維持整體統(tǒng)一性以及用戶體驗(yàn)，各模塊依然都會(huì)掛在統(tǒng)一的入口下。

上面所述場景就是典型的微前端場景，類似于后端的微服務(wù)架構(gòu)，它將web應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用。

通常，要實(shí)現(xiàn)上面類似的需求，我們很容易會(huì)想到使用iframe的方式來實(shí)現(xiàn)。在入口框架中用iframe來顯示子模塊的頁面，切換子模塊時(shí)，iframe也跟著切換成對應(yīng)子模塊頁面的url。

雖然iframe是比較容易實(shí)現(xiàn)的，但通常也會(huì)有一些問題：

顯示區(qū)域受限制，比如子項(xiàng)目中顯示彈窗蒙層時(shí)，蒙層只會(huì)覆蓋iframe區(qū)域，無法覆蓋整個(gè)頁面，內(nèi)容也無法真正居中。

頁面瀏覽記錄無法自動(dòng)被記錄，刷新頁面后iframe又自動(dòng)回到首頁。

全局上下文完全隔離，變量不共享，頁面間通信比較麻煩，比如子項(xiàng)目與主題框架、子項(xiàng)目之間通信等，只能采用postMessage方式。

速度較慢，每次進(jìn)入子應(yīng)用時(shí)都要重建整個(gè)上下文。

上面所列問題，有些可以解決，有些甚至都沒法或者很難解決?？偟膩碚f，iframe是一個(gè)比較快捷的方案，但不是最好的方案，會(huì)對體驗(yàn)有很多限制。如果強(qiáng)行打各種patch，復(fù)雜度又上來了，最后可能得不償失。

二、single-spa

剛才我們講了iframe實(shí)現(xiàn)微前端的一些弊端，主要原因就是這些應(yīng)用還是在各自獨(dú)立的頁面內(nèi)，這就導(dǎo)致了一些天然的限制。而single-spa微前端方案結(jié)合了MPA和SPA的優(yōu)勢，可以在單個(gè)頁面內(nèi)集成多個(gè)應(yīng)用，并且是技術(shù)棧無關(guān)的。

如上圖就是采用single-spa實(shí)現(xiàn)微前端的整體流程：

資源模塊加載器：用來加載子項(xiàng)目初始化資源。我們將子項(xiàng)目的入口js構(gòu)建成umd格式，然后使用模塊加載器遠(yuǎn)程加載，通常會(huì)使用SystemJs（不是必須）通用模塊加載器來進(jìn)行加載。

子應(yīng)用資源配置表：用來記錄各個(gè)子應(yīng)用的入口資源url信息，以便在切換不同子應(yīng)用時(shí)使用模塊加載器去遠(yuǎn)程加載。因?yàn)槊看巫討?yīng)用更新后入口資源的hash通常會(huì)變化，所以需要服務(wù)端定時(shí)去更新該配置表，以便框架能及時(shí)加載子應(yīng)用最新的資源。

注意：single-spa本身是不支持子應(yīng)用資源列表的，每個(gè)子應(yīng)用只能將自己所有初始化資源打包到一個(gè)入口js中。如果子應(yīng)用初始化資源有多個(gè)文件（可以通過webpack-manifest-plugin生成應(yīng)用初始化資源清單），就需要按照上述方式來添加額外處理。

1、框架入口

{ “imports”： { “app1”： “http://localhost:8081/js/app.js”， “app2”： “http://localhost:8082/js/app.js”， “single-spa”： “https://cdnjs.cloudflare.com/ajax/libs/single-spa/4.3.7/system/single-spa.min.js”， “vue”： “https://cdn.jsdelivr.net/npm/vue@2.6.10/dist/vue.js”， “vue-router”： “https://cdn.jsdelivr.net/npm/vue-router@3.0.7/dist/vue-router.min.js”， “vuex”： “https://cdnjs.cloudflare.com/ajax/libs/vuex/3.1.2/vuex.min.js” } }location.pathname.startsWith（‘/app2’） ） // 啟動(dòng) singleSpa.start（）; }） }）（）

為了簡單展示，上述只是框架入口html的一個(gè)簡單demo，并沒有解析子應(yīng)用資源配置表來加載相應(yīng)資源。在入口中我們注冊了子應(yīng)用，并確定了子應(yīng)用的激活時(shí)機(jī)。

子應(yīng)用資源配置表是完全自定義的，只要入口加載器這邊按照約定的規(guī)范來解析加載資源，并按照single-spa的生命周期鉤子來處理好這些資源的掛載。

我們還可以將一些公共的資源庫資源庫（如上vue、vue-router等）抽取到入口中，這樣各個(gè)子應(yīng)用不需要再包含這些庫文件了，可以減小資源文件大小，提升加載速度。子應(yīng)用中構(gòu)建時(shí)要外置這些庫，比如用webpack構(gòu)建時(shí)如下：

externals： ［‘vue’， ‘vue-router’， ‘vuex’］

2、子應(yīng)用入口

import ‘。/set-public-path’ import Vue from ‘vue’ import App from ‘。/App.vue’ import router from ‘。/router’ import singleSpaVue from ‘single-spa-vue’ Vue.config.productionTip = false if （process.env.NODE_ENV === ‘development’） { // 開發(fā)環(huán)境直接渲染 new Vue（{ router， render： h =》 h（App） }）.$mount（‘#app’） } const vueLifecycles = singleSpaVue（{ Vue， appOptions： { render： （h） =》 h（App）， router } }） export const bootstrap = vueLifecycles.bootstrap export const mount = vueLifecycles.mount export const unmount = vueLifecycles.unmount

如上我們的子應(yīng)用是vue開發(fā)的，需要用single-spa-vue來包裝下，然后導(dǎo)出生命周期的鉤子函數(shù)。為了方便開發(fā)，我們可以判斷下運(yùn)行環(huán)境，如果是開發(fā)環(huán)境的話，就直接渲染到頁面上。

set-public-path.js

細(xì)心的同學(xué)就會(huì)注意到，子應(yīng)用代碼中運(yùn)行了set-public-path.js。那么這個(gè)文件是干嘛用的呢？先來看下：

import { setPublicPath } from ‘systemjs-webpack-interop’ setPublicPath（‘a(chǎn)pp1’， 2）

從名字也能看出，systemjs-webpack-interop是針對在systemjs中使用webpack構(gòu)建的bundle的場景的。眾所周知，webpack構(gòu)建代碼時(shí)，可以通過output.publicPath選項(xiàng)指定要加載資源的url前綴，這在傳統(tǒng)的spa中不會(huì)有問題，但在single-spa的頁面中可能會(huì)有問題。比如output.publicPath： ‘/xx’的情況，webpack會(huì)認(rèn)為異步資源加載的url域名為當(dāng)前頁面的域名，這在傳統(tǒng)spa中不會(huì)有問題，但在single-spa的場景下異步資源就會(huì)加載失敗，因?yàn)樽討?yīng)用的異步資源與框架頁面的url域名并不是一樣的。所以需要各個(gè)子應(yīng)用自行在入口中執(zhí)行上述代碼，這會(huì)設(shè)置子應(yīng)用的異步資源url前綴與子應(yīng)用的入口js一致，這樣加載的路徑就不會(huì)錯(cuò)誤了。

setPublicPath代碼如下：

export function setPublicPath（systemjsModuleName， rootDirectoryLevel） { if （！rootDirectoryLevel） { rootDirectoryLevel = 1; } if （ typeof systemjsModuleName ！== “string” || systemjsModuleName.trim（）.length === 0 ） { throw Error（ “systemjs-webpack-interop： setPublicPath（systemjsModuleName） must be called with a non-empty string ‘systemjsModuleName’” ）; } if （ typeof rootDirectoryLevel ！== “number” || rootDirectoryLevel 《= 0 || ！Number.isInteger（rootDirectoryLevel） ） { throw Error（ “systemjs-webpack-interop： setPublicPath（systemjsModuleName， rootDirectoryLevel） must be called with a positive integer ‘rootDirectoryLevel’” ）; } let moduleUrl; try { moduleUrl = window.System.resolve（systemjsModuleName）; if （！moduleUrl） { throw Error（） } } catch （err） { throw Error（ “systemjs-webpack-interop： There is no such module ‘” + systemjsModuleName + “’ in the SystemJS registry. Did you misspell the name of your module？” ）; } __webpack_public_path__ = resolveDirectory（moduleUrl， rootDirectoryLevel）; } function resolveDirectory（urlString， rootDirectoryLevel） { const url = new URL（urlString）; const pathname = new URL（urlString）.pathname; let numDirsProcessed = 0， index = pathname.length; while （numDirsProcessed ！== rootDirectoryLevel && index 》= 0） { const char = pathname［--index］; if （char === “/”） { numDirsProcessed++; } } if （numDirsProcessed ！== rootDirectoryLevel） { throw Error（ “systemjs-webpack-interop： rootDirectoryLevel （” + rootDirectoryLevel + “） is greater than the number of directories （” + numDirsProcessed + “） in the URL path ” + fullUrl ）; } url.pathname = url.pathname.slice（0， index + 1）; return url.href; }

三、single-spa的不足

如上面提到過，如果子應(yīng)用初始化資源有多個(gè)文件（比如通常我們會(huì)將css、npm模塊抽離成一個(gè)單獨(dú)的文件），那么我們就要自行維護(hù)一個(gè)子應(yīng)用資源列表并做一些額外處理，這個(gè)工作往往也是比較繁瑣的；

將多個(gè)子應(yīng)用都集成在一個(gè)頁面中，css和js都是很有可能產(chǎn)生沖突的。雖然我們可以制定規(guī)范，比如各子項(xiàng)目使用唯一地命名前綴等，但這種人為約定往往又是不那么靠譜。對于css，我們還可以在構(gòu)建時(shí)使用一些工具自動(dòng)添加前綴，這樣可以比較靠譜的避免沖突；對于js來說，比較靠譜的方式可能就是人為制造沙箱，讓子應(yīng)用的js都運(yùn)行在各自的沙箱中，但這實(shí)現(xiàn)起來就比較復(fù)雜了。

四、qiankun

其實(shí)，已經(jīng)有個(gè)基于single-spa的開源庫qiankun已經(jīng)幫我們解決了上面提到的問題，其有如下特征：

解析子應(yīng)用入口時(shí)，不是解析的js文件，二是直接解析子應(yīng)用的html文件。就算子應(yīng)用更新了，其入口html文件的url始終不會(huì)變，并且完整的包含了所有的初始化資源url，所以不用再自行維護(hù)子應(yīng)用的資源列表了。

子應(yīng)用掛載時(shí)，會(huì)自動(dòng)進(jìn)行一些特殊處理，可以確保子應(yīng)用所有的資源dom（包括js添加的style標(biāo)簽等）都集中在子應(yīng)用根節(jié)點(diǎn)dom下。子應(yīng)用卸載時(shí)，對應(yīng)的整個(gè)dom都移除了，這樣也就避免了樣式?jīng)_突。

提供了js沙箱，子應(yīng)用掛載時(shí)，會(huì)對全局window對象代理、對全局事件監(jiān)聽進(jìn)行劫持等，確保各子應(yīng)用都運(yùn)行在自己的沙箱內(nèi)，這樣也就避免了js沖突。

包含多個(gè)spa應(yīng)用的demo

子應(yīng)用 dom 結(jié)構(gòu)如下

當(dāng)然，在前端越來越龐大復(fù)雜的場景中，微前端方案也不是銀彈，但確是值得探索實(shí)踐的方向。

五、參考文獻(xiàn)

single-spa

qiankun

可能是你見過最完善的微前端解決方案
編輯：hfy