後臺管理系統使用的是umi框架，隨著公司業務的發展，目前已經變成了一個巨石應用，越來越難維護，有必要對其進行拆分了。
計劃是從市面上挑選一個成熟的微前端框架，首先選擇的是 icestark，雖然文件中有說明umi框架的改造，但版本得是 3 以上。
而當前我們自己使用的版本是 1，差了整整兩個版本。然後再去搜索，發現另一個微前端框架：qiankun，並且它有一個 umi外掛。
但是又遇到了 umi版本的問題，好不容易找到一個諮詢umi改造微前端的問題，版本也是2。
本來是打算將老專案作為主應用，新專案作為微應用，但是現在因為版本的問題，難以實現。
那麼現在第一步是將umi升級，版本3的變化有點大，所以穩一點，先升級到版本 2。
一、umi升級
在官方文件中，有專門一頁講如何升級的，這個使用者體驗非常好。
一個清單列的非常清楚，內容不多，讓我信心大增。並且自己之前也曽依託 umi 2.0開源過一套系統。
所以在實際操作中，升級遇到的阻力沒有我想象中的那麼大，但期間還是遇到了些難纏的問題，諸如頁面空白，檔案不存在等。
具體的改造其實就那麼幾步，升級和替換依賴庫，更正路由配置，去除過時檔案等。
改造好後，自己粗略的刷刷頁面，沒啥問題，然後就開心地釋出到預發環境。但是在生成source map檔案時，報記憶體棧溢位。
source map檔案主要用於監控系統中的程式碼還原，在實際使用中用的比較少，那就先暫時關閉了。
不過在生產釋出的時候，又會報沒有source map檔案，因為生產有個將檔案搬移到指定位置的指令碼，得把這個指令碼也關閉。
二、Electron
公司管理後臺有一個監控直播的頁面，之前因為種種原因將頁面嵌在一個Electron中，而在那名老夥離職後，就處於無人維護的狀態。
近期對 umi 做了升級，在瀏覽器中可以正常訪問，但是放到此軟體中，就會變成空白，直覺告訴我JavaScript指令碼報錯了。
公司相關的人員還比較依賴此軟體，不能訪問會很影響他們的日常工作，所以得花時間解決掉這個問題。
在監控系統中選擇runtime錯誤，可以看到下面的錯誤資訊，但是這個錯誤還不夠具體。
{
"type": "runtime",
"lineno": 1,
"colno": 2831631,
"desc": "Uncaught TypeError: Cannot read property 'split' of undefined at https://xx.xx.me/umi.241e4aaf.js:1:2831631"
}
於是找到了一個名為Debugtron的工具，可以除錯Electron中的頁面（如下所示），在這個偵錯程式中就可以看到具體的錯誤以及出錯程式碼的位置。
這段錯誤出現在一個加密演算法庫中，經過曲折的排查後，定位到業務邏輯中會引用crypto，一旦引用這個庫就會報這個錯誤。
一開始判斷的錯誤是由於函式中傳入的process是undefined或沒有version欄位，而global.process是有值的，從而進入到該條分支中呼叫split()。不過在配置webpack引數後，並沒有解決該問題。
然後想在本地的node_modules中找到那段程式碼，註釋和列印變數，但總是無法生效。
接著通過檢視react的錯誤debug，找到了一段邏輯業務程式碼，將那個檔案註釋掉，居然能訪問了。
那是一段加密的邏輯，就用crypto-js替換crypto，但是兩者的加密無法互通。
休息了一會兒，和同事聊了下這個問題，他說服務端已經採用crypto-js封裝了一段加密，給了我靈感，那就將原先的加密替換掉。
全域性搜尋後發現只有一處引用了原先的加密邏輯，改造成本非常低，替換後，就能正常訪問了。
三、@umijs/plugin-qiankun
在將 umi 升級到版本2.x後，就安裝了 qiankun 外掛，不過使用的版本是 1.7.0。
隨後就是將原來的老專案配置為主應用，第一步是在 .umirc.js 中新增外掛的宣告。
export default {
plugins: [
[
'@umijs/plugin-qiankun',
{
master: {
// 註冊子應用資訊
apps: [
{
name: 'app1', // 唯一 id
entry: '//localhost:8001', // html entry
base: '/app1',
mountElementId: 'root-slave',
// history: 'browser',
},
// {
// name: 'app2', // 唯一 id
// entry: '//localhost:8002', // html entry
// base: '/app2',
// },
],
jsSandbox: true, // 是否啟用 js 沙箱
},
}
]
],
}
第二步是在主應用中新增 id=root-slave 的元素，我將其加在 layout/index.js 檔案中。
<div id="root-slave"></div>
若沒指明子應用的掛載點，那麼會報錯：
Application 'app1' died in status LOADING_SOURCE_CODE: Target container is not a DOM element
第三步是修改 document.ejs 中的根節點ID，不再是 root，而是 root-master。
<!-- <div id="root"></div> -->
<div id="root-master"></div>
第四步就是改造子應用，我直接下載了 umi 3.X 版本，在package.json 新增 name欄位，值為app1。並在.umirc.ts中新增 qiankun 的配置。
export default defineConfig({
routes: [
{ path: '/', component: '@/pages/index' },
{ path: '/index', component: '@/pages/index' },
],
qiankun: {
slave: {},
},
});
訪問主應用地址：http://localhost:8000/app1，就能在頁面中渲染出子應用，圖中紅色部分就是子應用介面。
但是注意，該子應用的路徑都是以 app1 開頭，所以子應用中的路由如果是 /index的話，那麼在主應用中的訪問就是 http://localhost:8000/app1/index。
當路由不匹配時，頁面就會出現未渲染的空白。至此，初步實現了微前端。
四、子應用
子應用使用的是umi 3.X，該版本預設將Ant Design升級到了4.X版本，4.X在使用上做了些調整。
在將通用模板元件和通用功能遷移到此框架中時，遇到了不少阻力。
1）廢棄Form.create()
首先是對通用元件中的表單做修改，因為該版本的 Form 不再需要通過 Form.create() 建立上下文，因此 getFieldDecorator() 函式也不再需要，改成了直接寫入 Form.Item。
// antd v3
const Demo = ({ form: { getFieldDecorator } }) => (
<Form>
<Form.Item>
{getFieldDecorator('username', {
rules: [{ required: true }],
})(<Input />)}
</Form.Item>
</Form>
);
// antd v4
const Demo = () => (
<Form>
<Form.Item name="username" rules={[{ required: true }]}>
<Input />
</Form.Item>
</Form>
);
2）validateFields()返回值修改
然後 validateFields() 也不再支援回撥，而是會返回 Promise 物件，因而可以通過 async/await 或者 then/catch 來執行對應的錯誤處理。
// antd v3
validateFields((err, value) => {
if (!err) {
// Do something with value
}
});
// antd v4
validateFields().then(values => {
// Do something with value
});
這兩個是比較大的改造，基本都是圍繞著它們做相容。
3）ICON按需引入
之後是 ICON 圖示引入的修正，新版本需要安裝 @ant-design/icons，然後按需引入 ICON 元件。
import { CheckCircleOutlined, PlusOutlined } from '@ant-design/icons';
新版本的Ant Design元件的圓角採用的是 2px，而之前版本的圓角是 4px，所以新版本會看上去更加尖銳。
4）DvaJS的TypeScript改造
除了對元件的修改之外，還修改了@umijs/plugin-dva的相關檔案，因為要符合 TypeScript 的語法，所以需要新增許多型別宣告。
import { Effect, ImmerReducer, Reducer, Subscription } from 'umi';
export interface IndexModelState {
name: string;
}
export interface IndexModelType {
namespace: 'index';
state: IndexModelState;
effects: {
query: Effect;
};
reducers: {
save: Reducer<IndexModelState>;
// 啟用 immer 之後
// save: ImmerReducer<IndexModelState>;
};
subscriptions: { setup: Subscription };
}
5）樣式隔離
在將子應用嵌入到主應用後，發現子應用的樣式影響了主應用中的部分樣式，所以需要將他們兩者隔離樣式。
為子應用的ConfigProvider元件新增prefixCls屬性，當然也可以在主應用中配置，但是主應用中涉及的頁面眾多，以防萬一還是在子應用中配置比較保險。
<ConfigProvider locale={zhCN} prefixCls="ant-slave">
<App {...data} />
</ConfigProvider>
並且在.umirc.ts檔案中修改Ant Design中的Less變數：@ant-prefix，若不與prefixCls對應，則整個頁面將會沒有樣式。
theme: {
'@ant-prefix': 'ant-slave',
},
五、主應用發起兩次請求
在具體使用時又發現了一個嚴重的問題，那就是當切換選單時，每個初始化的請求會發送兩次（如下圖所示），我這些請求都被封裝在 history.listen的回撥中。
subscriptions: {
setup({ dispatch, history }) {
history.listen((location) => {
if (location.pathname === '/developer/config') {
dispatch({
type: TEMPLATE_MODEL.QUERY,
payload: {
url: api.toolConfigQuery
}
});
}
});
},
},
在網上搜索，看到很多人也遇到了這個問題，究其原因是 popstate 事件觸發了兩次。緣由是因為：
single-spa改寫了window.history.pushState方法，在每次pushState的時候會主動dispatch一個popState事件，被history的checkDomListeners捕獲，這樣通過history.listen註冊的監聽函式都會被執行兩次。
既然知道了原因，那就可以對症下藥了，網上的一個issue說可以用 urlRerouteOnly 引數來控制呼叫 history.pushState 和 history.replaceState 時是否觸發一個 popstate 事件。
說幹就幹，在.umirc.js中新增urlRerouteOnly引數，自動重新整理頁面後，什麼也沒有改變，依舊是兩次，怎麼配都不行。
[
'@umijs/plugin-qiankun',
{
master: {
// 註冊子應用資訊
apps: [
{
name: 'app1', // 唯一 id
entry: '//localhost:8001', // html entry
base: '/app1',
mountElementId: 'root-slave',
},
],
jsSandbox: true, // 是否啟用 js 沙箱
urlRerouteOnly: true
},
}
]
那就直接檢視存在於 node_modules 的乾坤原始碼了（外掛的原始碼沒啥看頭），使用的版本是 1.5.2，找到了呼叫single-spa的start()方法的函式，發現並沒有傳遞我配置的引數。
import { registerApplication, start as startSingleSpa } from 'single-spa';
// opts引數包含urlRerouteOnly引數
export function start(opts) {
if (opts === void 0) {
opts = {};
}
// 省略中間邏輯
startSingleSpa();
frameworkStartedDefer.resolve();
}
本來以為是因為 start() 函式中未傳遞urlRerouteOnly引數導致問題仍然存在，但是將引數手動的傳入，問題並沒有被排除。
那麼接下來就得檢視 single-spa 的原始碼了，我發現與網上給出的原始碼不太一樣，原來我當前使用的版本是4.4.4（如下所示），而網上解決方案給出的是5.9.4。
window.history.pushState = function (state) {
var result = originalPushState.apply(this, arguments);
urlReroute(createPopStateEvent(state));
return result;
};
在 5.9.3 中提供了 urlRerouteOnly 引數來控制是否觸發 popstate 事件（如下所示），而舊版本是沒有這個控制選項的。
window.history.pushState = patchedUpdateState(
window.history.pushState,
"pushState"
);
function patchedUpdateState(updateState, methodName) {
return function () {
const urlBefore = window.location.href;
const result = updateState.apply(this, arguments);
const urlAfter = window.location.href; if (!urlRerouteOnly || urlBefore !== urlAfter) {
if (isStarted()) {
// fire an artificial popstate event once single-spa is started,
// so that single-spa applications know about routing that
// occurs in a different application
window.dispatchEvent(
createPopStateEvent(window.history.state, methodName)
);
} else {
// do not fire an artificial popstate event before single-spa is started,
// since no single-spa applications need to know about routing events
// outside of their own router.
reroute([]);
}
}
return result;
};
}
至此又回到了原點，網上還有另一種臨時的解決方案，那就是改造 react-router-dom/BrowserRouter，在建構函式中覆蓋 history.listen，並加個路徑判斷。
若當前路徑和上一個路徑相同，那麼就直接返回，停止後面的邏輯。不過個人感覺這樣侵入性比較大，很有可能造成非常隱蔽的錯誤。
export default class BrowserRouter extends React.Component<BrowserRouterProps> {
private history: History
constructor(props) {
super(props)
this.history = createHistory(this.props)
const rawHistory = this.history.listen.bind(this.history)
// 臨時解決方案
this.history.listen = (listener: LocationListener<LocationState>): UnregisterCallback => {
let lastPathname = null
function enhancerCb(...args) {
const [location] = args
if (location.pathname === lastPathname) return
lastPathname = location.pathname
// @ts-ignore
return listener(...args)
}
return rawHistory(enhancerCb)
}
}
}
我在此思路上做了些修改，我封裝了一個方法，首先想到的是判斷當前路徑和上一條路徑的相等性，但遇到一個問題。
export function listenHoc(history, callback) {
let lastPath;
history.listen((location) => {
if (location.pathname === lastPath) return
lastPath = location.pathname
callback(location);
});
}
當點選一個選單項，能夠阻止第二次的請求，但是我再點選相同的選單項，就會不再請求了。因為此時lastPath和location.pathname是相等的。
經過觀察，發現location有個key屬性，每次點選選單就會重新生成key，可以用此屬性來做二次請求的判斷依舊。
export function listenHoc(history, callback) {
let lastKey;
history.listen((location) => {
if (location.key === lastKey) return
lastKey = location.key
callback(location);
});
}
這麼做的好處是靈活性高，並且都在我的控制之中，還不會影響其他第三方庫。最大的壞處就是要修改許多Model檔案，改變呼叫方式。
在實際使用中馬上暴露一個問題，那就是當直接在工具欄中輸入地址回車後。
location.key的值是undefined，而lastKey也是undefined，由此兩者匹配就會相同，也就會終止接下去的邏輯。
那麼為了避免這種情況，需要新增一個條件限制。
export function listenHoc(history, callback) {
let lastKey;
history.listen((location) => {
if (location.key !== undefined && (location.key === lastKey)) return
lastKey = location.key
callback(location);
});
}
六、部署
在解決完這個問題後，就將子應用部署到伺服器上，雖然在本地訪問子應用，需要配置某個埠，但是在線上並不需要單獨配置埠，預設80埠足矣。
為了方便，連域名也沒有單獨申請，沿用主應用的域名，在Nginx上僅僅做了次轉發，如下所示。這樣當訪問 xx.xx.com/app1/ 時，呈現的就是子應用的介面。
xx.xx.com/app1/(.*) -> appts
但是在訪問時，發現該專案的指令碼檔案沒有被正確讀取，檢視頁面發現指令碼讀取的是根目錄的umi.js，也就是主應用的指令碼。
<script src="/umi.js" entry=""></script>
而我們需要的是子應用的指令碼，因此，需要在 .umirc.ts 檔案中手動配置靜態資源路徑。
export default defineConfig({
publicPath: '/app1/', //靜態資源路徑
});
在主應用的.umirc.js配置檔案中，需要有環境的判斷，umi中的process.env.NODE_ENV是寫死的，dev 時為 development，build 時為 production。
在本地開發時，可以自定義埠，但是掛在伺服器上就需要通過域名來訪問了，此時的配置就會不同。
[
'@umijs/plugin-qiankun',
{
master: {
apps: [
{
name: 'app1',
entry: (process.env.NODE_ENV === 'development' ? '//localhost:8001' : '/app1/'),
base: '/app1',
mountElementId: 'root-slave',
},
],
jsSandbox: true,
},
}
]
]