&emsp;&emsp;后臺管理系統使用的是[umi](https://umijs.org/zh-CN)框架，隨著公司業務的發展，目前已經變成了一個巨石應用，越來越難維護，有必要對其進行拆分了。 &emsp;&emsp;計劃是從市面上挑選一個成熟的微前端框架，首先選擇的是[icestark](https://micro-frontends.ice.work/docs/guide/)，雖然文檔中有說明umi框架的改造，但版本得是 3 以上。 &emsp;&emsp;而當前我們自己使用的版本是 1，差了整整兩個版本。然后再去搜索，發現另一個微前端框架：[qiankun](https://qiankun.umijs.org/zh)，并且它有一個[umi插件](https://umijs.org/zh-CN/plugins/plugin-qiankun)。 &emsp;&emsp;但是又遇到了 umi版本的問題，好不容易找到一個咨詢umi改造微前端的問題，版本也是2。 &emsp;&emsp;本來是打算將老項目作為主應用，新項目作為微應用，但是現在因為版本的問題，難以實現。 &emsp;&emsp;那么現在第一步是將umi升級，版本3的變化有點大，所以穩一點，先升級到版本 2。 ## 一、umi升級 &emsp;&emsp;在官方文檔中，有專門一頁講[如何升級](https://v2.umijs.org/zh/guide/migration.html)的，這個用戶體驗非常好。 &emsp;&emsp;一個清單列的非常清楚，內容不多，讓我信心大增。并且自己之前也曽依托 umi 2.0開源過[一套系統](https://github.com/pwstrick/shin-admin)。 &emsp;&emsp;所以在實際操作中，升級遇到的阻力沒有我想象中的那么大，但期間還是遇到了些難纏的問題，諸如頁面空白，文件不存在等。 &emsp;&emsp;具體的改造其實就那么幾步，升級和替換依賴庫，更正路由配置，去除過時文件等。 &emsp;&emsp;改造好后，自己粗略的刷刷頁面，沒啥問題，然后就開心地發布到預發環境。但是在生成source map文件時，報內存棧溢出。 &emsp;&emsp;source map文件主要用于[監控系統](https://www.cnblogs.com/strick/p/14577054.html)中的代碼還原，在實際使用中用的比較少，那就先暫時關閉了。 &emsp;&emsp;不過在生產發布的時候，又會報沒有source map文件，因為生產有個將文件搬移到指定位置的腳本，得把這個腳本也關閉。 ## 二、Electron &emsp;&emsp;公司管理后臺有一個監控直播的頁面，之前因為種種原因將頁面嵌在一個[Electron](https://www.electronjs.org/)中，而在那名老伙離職后，就處于無人維護的狀態。 &emsp;&emsp;近期對 umi 做了升級，在瀏覽器中可以正常訪問，但是放到此軟件中，就會變成空白，直覺告訴我JavaScript腳本報錯了。 &emsp;&emsp;公司相關的人員還比較依賴此軟件，不能訪問會很影響他們的日常工作，所以得花時間解決掉這個問題。 &emsp;&emsp;在[監控系統](https://www.cnblogs.com/strick/p/14577054.html)中選擇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" } ~~~ &emsp;&emsp;于是找到了一個名為[Debugtron](https://github.com/bytedance/debugtron/releases)的工具，可以調試Electron中的頁面（如下所示），在這個調試器中就可以看到具體的錯誤以及出錯代碼的位置。 :-:  &emsp;&emsp;這段錯誤出現在一個加密算法庫中，經過曲折的排查后，定位到業務邏輯中會引用[crypto](https://github.com/npm/deprecate-holder)，一旦引用這個庫就會報這個錯誤。 &emsp;&emsp;一開始判斷的錯誤是由于函數中傳入的process是undefined或沒有version字段，而global.process是有值的，從而進入到該條分支中調用split()。不過在配置webpack參數后，并沒有解決該問題。 &emsp;&emsp;然后想在本地的node\_modules中找到那段代碼，注釋和打印變量，但總是無法生效。 &emsp;&emsp;接著通過查看react的錯誤debug，找到了一段邏輯業務代碼，將那個文件注釋掉，居然能訪問了。 &emsp;&emsp;那是一段加密的邏輯，就用[crypto-js](https://github.com/brix/crypto-js)替換crypto，但是兩者的加密無法互通。 &emsp;&emsp;休息了一會兒，和同事聊了下這個問題，他說服務端已經采用crypto-js封裝了一段加密，給了我靈感，那就將原先的加密替換掉。 &emsp;&emsp;全局搜索后發現只有一處引用了原先的加密邏輯，改造成本非常低，替換后，就能正常訪問了。 ## 三、@umijs/plugin-qiankun &emsp;&emsp;在將 umi 升級到版本2.x后，就安裝了 qiankun 插件，不過使用的版本是[1.7.0](https://www.npmjs.com/package/@umijs/plugin-qiankun/v/1.7.0)。 &emsp;&emsp;隨后就是將原來的老項目配置為主應用，第一步是在 .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 沙箱 }, } ] ], } ~~~ &emsp;&emsp;第二步是在主應用中添加 id=root-slave 的元素，我將其加在 layout/index.js 文件中。 ~~~ <div id="root-slave"></div> ~~~ &emsp;&emsp;若沒指明子應用的掛載點，那么會報錯： ~~~ Application 'app1' died in status LOADING_SOURCE_CODE: Target container is not a DOM element ~~~ &emsp;&emsp;第三步是修改 document.ejs 中的根節點ID，不再是 root，而是 root-master。 ~~~ <!-- <div id="root"></div> --> <div id="root-master"></div> ~~~ &emsp;&emsp;第四步就是改造子應用，我直接下載了 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: {}, }, }); ~~~ &emsp;&emsp;訪問主應用地址：http://localhost:8000/app1，就能在頁面中渲染出子應用，圖中紅色部分就是子應用界面。  &emsp;&emsp;但是注意，該子應用的路徑都是以 app1 開頭，所以子應用中的路由如果是 /index的話，那么在主應用中的訪問就是 http://localhost:8000/app1/index。 &emsp;&emsp;當路由不匹配時，頁面就會出現未渲染的空白。至此，初步實現了微前端。 ## 四、子應用 &emsp;&emsp;子應用使用的是umi 3.X，該版本默認將Ant Design升級到了[4.X](https://ant.design/index-cn)版本，4.X在使用上做了些調整。 &emsp;&emsp;在將通用模板組件和通用功能遷移到此框架中時，遇到了不少阻力。 **1）廢棄Form.create()** &emsp;&emsp;首先是對通用組件中的[表單做修改](https://ant.design/components/form/v3-cn)，因為該版本的 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()返回值修改** &emsp;&emsp;然后 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 }); ~~~ &emsp;&emsp;這兩個是比較大的改造，基本都是圍繞著它們做兼容。 **3）ICON按需引入** &emsp;&emsp;之后是 ICON 圖標引入的修正，新版本需要安裝 @ant-design/icons，然后按需引入 ICON 組件。 ~~~ import { CheckCircleOutlined, PlusOutlined } from '@ant-design/icons'; ~~~ &emsp;&emsp;新版本的Ant Design組件的圓角采用的是 2px，而之前版本的圓角是 4px，所以新版本會看上去更加尖銳。 **4）DvaJS的TypeScript改造** &emsp;&emsp;除了對組件的修改之外，還修改了[@umijs/plugin-dva](https://umijs.org/zh-CN/plugins/plugin-dva#model-%E7%94%A8%E4%BE%8B)的相關文件，因為要符合 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）樣式隔離** &emsp;&emsp;在將子應用嵌入到主應用后，發現子應用的樣式影響了主應用中的部分樣式，所以需要將他們兩者隔離樣式。 &emsp;&emsp;為子應用的ConfigProvider組件添加prefixCls屬性，當然也可以在主應用中配置，但是主應用中涉及的頁面眾多，以防萬一還是在子應用中配置比較保險。 ~~~html <ConfigProvider locale={zhCN} prefixCls="ant-slave"> <App {...data} /> </ConfigProvider> ~~~ &emsp;&emsp;并且在.umirc.ts文件中修改Ant Design中的Less變量：@ant-prefix，若不與prefixCls對應，則整個頁面將會沒有樣式。 ~~~ theme: { '@ant-prefix': 'ant-slave', }, ~~~ ## 五、主應用發起兩次請求 &emsp;&emsp;在具體使用時又發現了一個嚴重的問題，那就是當切換菜單時，每個初始化的請求會發送兩次（如下圖所示），我這些請求都被封裝在 history.listen的回調中。 :-:  ~~~ subscriptions: { setup({ dispatch, history }) { history.listen((location) => { if (location.pathname === '/developer/config') { dispatch({ type: TEMPLATE_MODEL.QUERY, payload: { url: api.toolConfigQuery } }); } }); }, }, ~~~ &emsp;&emsp;在網上搜索，看到很多人也遇到了這個問題，究其原因是 popstate 事件觸發了兩次。[緣由](https://github.com/umijs/umi/issues/3919)是因為： &emsp;&emsp;single-spa改寫了window.history.pushState方法，在每次pushState的時候會主動dispatch一個popState事件，被history的checkDomListeners捕獲，這樣通過history.listen注冊的監聽函數都會被執行兩次。 &emsp;&emsp;既然知道了原因，那就可以對癥下藥了，網上的一個[issue](https://github.com/umijs/qiankun/issues/1339)說可以用 urlRerouteOnly 參數來控制調用 history.pushState 和 history.replaceState 時是否觸發一個 popstate 事件。 &emsp;&emsp;說干就干，在.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 }, } ] ~~~ &emsp;&emsp;那就直接查看存在于 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(); } ~~~ &emsp;&emsp;本來以為是因為 start() 函數中未傳遞urlRerouteOnly參數導致問題仍然存在，但是將參數手動的傳入，問題并沒有被排除。 &emsp;&emsp;那么接下來就得查看 single-spa 的源碼了，我發現與網上給出的源碼不太一樣，原來我當前使用的版本是4.4.4（如下所示），而網上解決方案給出的是5.9.4。 ~~~ window.history.pushState = function (state) { var result = originalPushState.apply(this, arguments); urlReroute(createPopStateEvent(state)); return result; }; ~~~ &emsp;&emsp;在 5.9.3 中提供了[urlRerouteOnly](https://github.com/single-spa/single-spa/blob/f28b5963be1484583a072c8145ac0b5a28d91235/src/navigation/navigation-events.js#L100)參數來控制是否觸發 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; }; } ~~~ &emsp;&emsp;至此又回到了原點，網上還有另一種臨時的[解決方案](https://github.com/umijs/qiankun/issues/1184)，那就是改造 react-router-dom/BrowserRouter，在構造函數中覆蓋 history.listen，并加個路徑判斷。 &emsp;&emsp;若當前路徑和上一個路徑相同，那么就直接返回，停止后面的邏輯。不過個人感覺這樣侵入性比較大，很有可能造成非常隱蔽的錯誤。 ~~~ 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) } } } ~~~ &emsp;&emsp;我在此思路上做了些修改，我封裝了一個方法，首先想到的是判斷當前路徑和上一條路徑的相等性，但遇到一個問題。 ~~~ export function listenHoc(history, callback) { let lastPath; history.listen((location) => { if (location.pathname === lastPath) return lastPath = location.pathname callback(location); }); } ~~~ &emsp;&emsp;當點擊一個菜單項，能夠阻止第二次的請求，但是我再點擊相同的菜單項，就會不再請求了。因為此時lastPath和location.pathname是相等的。 &emsp;&emsp;經過觀察，發現location有個key屬性，每次點擊菜單就會重新生成key，可以用此屬性來做二次請求的判斷依舊。 ~~~ export function listenHoc(history, callback) { let lastKey; history.listen((location) => { if (location.key === lastKey) return lastKey = location.key callback(location); }); } ~~~ &emsp;&emsp;這么做的好處是靈活性高，并且都在我的控制之中，還不會影響其他第三方庫。最大的壞處就是要修改許多Model文件，改變調用方式。 &emsp;&emsp;在實際使用中馬上暴露一個問題，那就是當直接在工具欄中輸入地址回車后。 &emsp;&emsp;location.key的值是undefined，而lastKey也是undefined，由此兩者匹配就會相同，也就會終止接下去的邏輯。 &emsp;&emsp;那么為了避免這種情況，需要添加一個條件限制。 ~~~ export function listenHoc(history, callback) { let lastKey; history.listen((location) => { if (location.key !== undefined && (location.key === lastKey)) return lastKey = location.key callback(location); }); } ~~~ ## 六、部署 &emsp;&emsp;在解決完這個問題后，就將子應用部署到服務器上，雖然在本地訪問子應用，需要配置某個端口，但是在線上并不需要單獨配置端口，默認80端口足矣。 &emsp;&emsp;為了方便，連域名也沒有單獨申請，沿用主應用的域名，在Nginx上僅僅做了次轉發，如下所示。這樣當訪問 xx.xx.com/app1/ 時，呈現的就是子應用的界面。 ~~~ xx.xx.com/app1/(.*) -> appts ~~~ &emsp;&emsp;但是在訪問時，發現該項目的腳本文件沒有被正確讀取，查看頁面發現腳本讀取的是根目錄的umi.js，也就是主應用的腳本。 ~~~html <script src="/umi.js" entry=""></script> ~~~ &emsp;&emsp;而我們需要的是子應用的腳本，因此，需要在 .umirc.ts 文件中手動配置靜態資源路徑。 ~~~ export default defineConfig({ publicPath: '/app1/', //靜態資源路徑 }); ~~~ &emsp;&emsp;在主應用的.umirc.js配置文件中，需要有環境的判斷，umi中的process.env.NODE\_ENV是寫死的，dev 時為 development，build 時為 production。 &emsp;&emsp;在本地開發時，可以自定義端口，但是掛在服務器上就需要通過域名來訪問了，此時的配置就會不同。 ~~~ [ '@umijs/plugin-qiankun', { master: { apps: [ { name: 'app1', entry: (process.env.NODE_ENV === 'development' ? '//localhost:8001' : '/app1/'), base: '/app1', mountElementId: 'root-slave', }, ], jsSandbox: true, }, } ] ] ~~~ ***** > 原文出處： [博客園-Node.js躬行記](https://www.cnblogs.com/strick/category/1688575.html) [知乎專欄-Node.js躬行記](https://zhuanlan.zhihu.com/pwnode) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。