一、背景

業(yè)務背景

得物效率前端所在的效率工程為提升企業(yè)協(xié)作效率而生，面臨大量的 PC 側(cè)的中后臺應用場景。

在之前的微信公眾號《得物效率前端微應用推進過程與思考》中詳細介紹了效率前端推進微應用落地的思路和部分效果。

這篇文章將著重介紹得物效率前端微應用推進中，微前端的研發(fā)效率遇到的挑戰(zhàn)和解決方案。

名詞解釋

微應用

「微應用」是得物效率前端內(nèi)部稱謂，是一個基于“monorepo & 微前端 & 基座與業(yè)務分離”的、包括“文檔 & 工具”的一套體系化降低研發(fā)成本和提升用戶體驗的技術產(chǎn)品。

微前端

「微前端」是得物效率前端微應用推進的重要一環(huán)，尤其是父子應用技術棧不同時，利用 iframe / qiankun / wujie / micro-app 等工具進行微前端化改造，能顯著增強業(yè)務擴展性。

圖片

基座應用/父應用

微前端中，基座應用（父應用）、子應用是常見概念，本文描述中，“基座應用”又名“父應用”，為簡化文案，“基座應用與子應用”也被稱為“父子應用”。

瀏覽器插件/擴展

chrome://extensions/ 頁面中對第三方工具稱為“擴展”，在本文語境下，又稱為“插件”。

二、研發(fā)費力度痛點

就研發(fā)效率而言，微前端在團隊多個業(yè)務落地后，面臨研發(fā)過程費力度高的問題。

費力點1

本地開發(fā)時，從啟動 1 個本地服務，變?yōu)樾鑶?2 個本地服務：

大大多數(shù)情況下，項目需要啟動  2 個本地服務（基座應用和子應用）才能進行日常開發(fā)，因為子應用通常依賴基座應用透傳一些依賴數(shù)據(jù)。

而非微前端場景下，啟動 1 個應用就可以了，這反而引入了降低了研發(fā)效率。雖然微前端方案更注重業(yè)務效率，但研發(fā)效率也是必須要考慮的。

如果電腦性能一般的話，卡頓問題就隨之而來了。

費力點2

基座應用本地代碼需要做適配性改造：

如父應用需要區(qū)分本地環(huán)境和生產(chǎn)環(huán)境類似這樣的代碼，雖然代碼量不大，但還是需要關注的：

// 基座代碼
if (isLocal) {
    return <microapppage src="localhost://8000/a/b/c" />
} else if (isProd) {
    return <microapppage src="https://www.abc.com/a/b/c">
}

費力點3

頻繁無規(guī)律刷新：

在 Qiankun 微前端框架且本地開發(fā)環(huán)境下，基座應用與子應用頁面均需要 WebSocket 與其自身本地服務進行通信。

在同時啟動基座與子應用的本地服務后，修改子應用代碼以及偶發(fā)的，頁面會觸發(fā) Reload，而不是局部更新，開發(fā)體驗很差。針對這個問題我們做了一些分析。

HMR 的熱更新邏輯

本地開發(fā)過程會啟動 Webpack-Dev-Server 服務，其會監(jiān)聽業(yè)務文件變化，瀏覽器通過 WebSocket 與 Webpack-Dev-Server 進行通信。

當發(fā)現(xiàn)文件內(nèi)容改變時 Webpack-Dev-Server 會根據(jù)更新的文件內(nèi)容生成 Hash 信息傳遞給瀏覽器，如圖：

圖片

當瀏覽器收到信息時，會根據(jù)收到的信息和配置進行判斷是刷新操作還是熱更新操作。熱更新時，Webpack-Dev-Serer 通過 Jsonp 拉取最新的 JS 模塊代碼，并進行模塊替換，如圖：

圖片

若此過程異常，則會降級為頁面刷新。

無規(guī)律刷新原因分析

基座應用（端口 8010）熱更新時返回的文件 Json 和 JS 文件（分別是 **:8010/update.json 和 **:8010/update.js）內(nèi)容如下：

圖片

圖片

但在嵌套在基座應用中的本地子應用（端口 8020）熱更新時，兩個同類文件并沒有返回內(nèi)容（**:8020/update.json 和 **:8020/update.js）

圖片

圖片

若瀏覽器單獨打開兩個文件的地址（**:8020/update.json 和 **:8020/update.js），有內(nèi)容返回。

圖片

但是在基座與子應用嵌套的情況下，子應用的任何請求（包括 update.json / update.js ）都會被基座應用代理，開發(fā)環(huán)境下很容易出現(xiàn)子應用的更新探針請求被基座代理后，出現(xiàn)內(nèi)容丟失的情況。

子應用 HMR 邏輯檢測到更新探針請求內(nèi)容異常，局部更新失效，降級為頁面刷新。

即使該問題解決，微前端應用開發(fā)者依然面臨同時啟動 2 個應用才能啟動開發(fā)的問題，所以我們不過度投入精力關注這個問題。

三、技術調(diào)研

解決「默認情況下，父子應用需要分別獨立啟動，并指定關聯(lián)關系」的問題，最好的方式是回歸到非微前端場景下的常規(guī)開發(fā)方式，即只啟動 1 個應用進行本地開發(fā)。

通常情況下，我們開發(fā)的是子應用（也就是業(yè)務頁面），那先實現(xiàn)子應用單獨啟動即可開啟項目開發(fā)吧，以下是面向該需求的技術調(diào)研。

Shared 通信

Shared 通信方案的原理是，主應用維護一個狀態(tài)池，通過 Shared 實例暴露一些方法給子應用使用。

同時，子應用需要單獨維護一份 Shared 實例，在獨立運行時使用自身的 Shared 實例，在嵌入主應用時使用主應用的 Shared 實例，這樣就可以保證在使用和表現(xiàn)上的一致性。

Shared 通信方案要求父子應用都各自維護一份屬于自己的 Shared 實例，同樣會增加項目的復雜度。同時，在子應用獨立運行時，Shared 只能獲取本地緩存數(shù)據(jù)，無法真正做到完全獨立于子應用運行。

圖片

Mock 父應用環(huán)境

也就是在子應用中模擬父應用嵌套環(huán)境，提供一個獨立的模擬父應用的組件，封裝了 Layout 布局、權限、用戶信息等，并且具備必要的父子通信能力，子應用調(diào)用該 Mock 組件，獨立啟動以后進行日常開發(fā)。

這個方案和 Shared 通信有類似之處。

用戶體驗

// 這是子應用代碼


import { MicroLayout } from '@abc/components';


//  組件內(nèi)使用
<MicroLayout title="Layout 內(nèi)容">
    {children}
</MicroLayout>

圖片

流程設計

圖片

其他

對業(yè)務開發(fā)者而言，基座應用 Layout 的改動均需要使用者進行 Mock Component 的升級，比較麻煩。

對 Mock Component 開發(fā)者而言，需要額外開發(fā)父子通信方案 Microservice，用于 Mock Component 與子應用的通信。

這套方案在應對比較簡單的甚至沒有數(shù)據(jù)傳輸?shù)奈蒙鲜强梢缘?，但是對于自定義化程度較高，復雜程度較高的微應用項目來說就不是很方便了。

四、Chrome 代理插件

也就是通過 Chrome 插件，將線上子應用 URL 代理到本地代碼。

利用瀏覽器提供的插件特性，劫持 HTTP 請求，將已經(jīng)部署在測試/預發(fā)/線上環(huán)境的項目的微應用部分代理到開發(fā)者本地啟動的項目，這樣可以不用啟動基座應用，直接打開目標環(huán)境的主應用，卻可以訪問本地子應用項目進行開發(fā)工作。

用戶體驗

圖片

其他

子應用需要的數(shù)據(jù)通過目標環(huán)境的父應用獲得，和第一套方案相比，他既可以滿足復雜場景下的子應用獨立啟動，也不需要關注每個接入的子應用他的數(shù)據(jù)依賴關系，研發(fā)成本也較低。

圖片

四、Chrome 代理插件

產(chǎn)品設計

“Chrome 插件代理子應用到本地代碼”以提升微前端研發(fā)效率，該瀏覽器插件需要具備以下核心能力：

圖片

規(guī)則靈活配置。插件實現(xiàn)了 from 和 to 的地址映射規(guī)則配置表單。

如下圖，所有含 https://t1-xxxxxxxx.net/microapp/ 路徑的請求都將被代理到 localhost:8020/microapp/。

圖片

2. 緩存能力。用戶關閉瀏覽器/電腦后再次打開，仍然能夠使用之前保存的代理規(guī)則。
3. 快捷操作。為常用產(chǎn)品配置內(nèi)置規(guī)則，一鍵即可啟動，非常方便。
4. 實時顯示。需要實時顯示代理規(guī)則的生效情況，方便用戶確認哪些規(guī)則正在生效。

技術設計

Proxy 和 Popup

Chrome 插件分為 2 個模塊：Proxy 代理劫持模塊和 Popup 用戶交互模塊。

圖片

功能流轉(zhuǎn)

圖片

無感更新（Seamless Update）

圖片

popup.html 作為用戶界面入口，動態(tài)引入 popup.js 處理用戶交互，popup.js 動態(tài)引入 proxy.js 執(zhí)行 url 攔截規(guī)則。

這么做需要在 chrome 插件的 csp 安全策略配置中加入 cdn 域名白名單，允許插件訪問外部 cdn 資源。

manifest.json 配置如下：

值得注意的是，無感更新方案只在 Chrome V2 中實現(xiàn)了，V3 版本的 Chrome 插件執(zhí)行了更為保守的安全策略，限制第三方資源的加載。

{
...
"permissions": [
  "webRequest", // 允許瀏覽器開放http請求劫持的功能
  "storage", // 允許使用瀏覽器緩存
  "activeTab", 
  "background", 
  "webRequestBlocking",
  "<all_urls>"
],
// 允許特定域名可以訪問的安全策略
"content_security_policy":"script-src 'self' https://cdn.xxxxx.com 'sha256-G7YAg/PQDo8GYc/fSYvWtXP98kXS7iqT7K4QZgyhUIE='; object-src 'self'",
"content_scripts": [
  {
    "matches": ["*://*.xxxxxxx.net/*"],
    "js": ["contentScript.bundle.js"]
  }
]
}
// ==========attentinotallow===========
//v2配置，v2版本中可以配置script等通過外部引入，這個content_security_policy配置參數(shù)不加或者加上之后相應的值填none
"content_security_policy": "script-src 'none'; object-src 'none'",


//v3配置，v3版本中安全政策配置script引入等信息，都必須填寫self，即只允許script標簽引用當前插件內(nèi)部文件，不允許引用外部鏈接，如果不填寫self的話，插件添加到擴展程序時會報錯
"content_security_policy": {
//原文：此政策涵蓋您的擴展程序中的頁面，包括 html 文件和服務人員；
"extension_pages": "script-src 'self'; object-src 'self'",


//原文：此政策涵蓋您的擴展程序使用的任何[沙盒擴展程序頁面](https://developer.chrome.com/docs/extensions/mv3/manifest/sandbox/)。；
"sandbox": "sandbox allow-scripts; script-src 'self'; object-src 'self'"
},

在 popup.html 中動態(tài)引入 popup.js 示例：

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Popup</title>
    <script>
      var scriptEl = document.createElement('script');
      scriptEl.defer = "defer";
      scriptEl.src = "https://cdn.xxxxxxxxxxx/popup.js?timestamp=" + Date.now();
      document.getElementsByTagName('head')[0].appendChild(scriptEl);
</script>  
  </head>


  <body>
    <div id="app-container"></div>
  </body>
</html>

各模塊 JS 在構建后上傳至 CDN，再在 popup.html / background.js / ... 中動態(tài)引入以實現(xiàn)無感更新。

圖片

Proxy

1. 攔截頁面請求。
2. 提供緩存配置的功能，用戶在關閉瀏覽器后，配置的映射關系不會自動消失，以便用戶下次打開的時候正常提供服務。
3. 通信功能，需要將用戶在 Popup 頁面交互時提交的數(shù)據(jù)地址數(shù)據(jù)提供給攔截方法，從而實現(xiàn)對應的攔截效果。
4. 提供配置信息狀態(tài)的緩存數(shù)據(jù)，方便觀測攔截效果。

以下是攔截邏輯的相關代碼：

chrome.webRequest.onBeforeRequest.addListener(
  worker.getRequest.bind(worker),
  {urls: worker.getFilterUrls(worker.replaceRules)},
  ['blocking']
);
// Class background 
class Background {
    constructor() {
    this.replaceRules = []
    }
    getRequest(details) {
      if (!details) {
        // chrome未返回任何request
        return false
      }
      const {url} = details
      const returnObj = {}
      if (this.replaceRules.length) {
        // 存在替換規(guī)則
        this.replaceRules.map((item) => {
          if (url.includes(item.from)) {
            // 更新 icon 狀態(tài)
            this.setBadgeInfo(true)
            // 代理替換
            returnObj.redirectUrl = url.replace(item.from, item.to)
            // 緩存更新當前代理域名
            chrome.storage.sync.get(null, function (data) {
              if (data.messageProxyingData) {
                // 存在被代理的數(shù)據(jù)，合并數(shù)據(jù)
                const isExistMessageProxyingData = data.messageProxyingData
                chrome.storage.sync.set({messageProxyingData: Object.assign(isExistMessageProxyingData, {[item.key]: true})})
              } else {
                // 未存在緩存，使用新數(shù)據(jù)
                chrome.storage.sync.set({messageProxyingData: {[item.key]: true}})
              }
            })
          }
        })
      }
      return returnObj
    }
}

可以看到，chrome.webRequest.onBeforeRequest/ getRequest 配合攔截獲取請求地址，然后攔截替換目標路徑，當然這是比較簡單的邏輯，復雜的可以參考 glob 寫法代理鏈接。

Popup

Popup 用戶交互模塊，支持一鍵開啟和一鍵關閉、支持自定義配置映射地址。

圖片

const sendMessage = (data: DataType[]) => {
  // 保留數(shù)據(jù)中已開啟的數(shù)據(jù)，進行數(shù)據(jù)傳輸
  const finalData = data.filter.((item) => item.is_open);
  chrome.runtime.sendMessage({ data: finalData, type: 'rule' });
};
const handleSaveData = (
  data: DataType[],
  isNeedSendMsg: boolean,
  key?: number[]
) => {
  setDataSource([...data]);
  // 緩存配置
  chrome.storage.sync.set({ popupData: data });
  if (isNeedSendMsg) {
    sendMessage(data);
    if (key?.length) {
      chrome.storage.sync.get(null, function (data) {
        const messageProxyingData = data.messageProxyingData || {};
        if (messageProxyingData) {
          key.forEach.((item) => {
            delete messageProxyingData[item];
          });
        }
        chrome.storage.sync.set({ messageProxyingData });
      });
    }
  }
};

ContentScript

原本無需在 ContentScript 中植入代理相關的任何邏輯，但在 Qiankun 微前端場景下有一個問題，子應用的熱更新會失效（可能導致 HMR 無效進而只能 Reload 頁面查看最新頁面效果），為此我們正好可以借助 Chrome 插件可注入 ContentScript 的能力，為用戶自動規(guī)避一些問題。

下面這段注入頁面的 ContentScript 可以輔助解決 Qiankun 子應用代碼更新后 HMR 失效的問題（方案來自社區(qū)）。

const scrpit = document.createElement('script')
scrpit.textContent = `
window.__REACT_ERROR_OVERLAY_GLOBAL_HOOK__ =
        window.__REACT_ERROR_OVERLAY_GLOBAL_HOOK__ || {
            iframeReady: function () {
                var overlay = document.querySelector(
                    'iframe[style*="z-index: 2147483647;"]',
                );
                if (overlay) {
                    overlay.style.display = 'none';
                }
            },
        };
`
document.body.appendChild(scrpit)

五、推進情況

項目覆蓋率

研發(fā)效率

1. 避免了父子應用均啟動時，子應用代碼更新后，父應用被動觸發(fā) Reload 的問題。
2. 子應用 HMR 熱更新延時與非微前端項目沒有差距。

用戶反饋

同時，Chrome 插件方案實現(xiàn)簡單、使用方便，是此類場景下，在研發(fā)成本和用戶體驗上的表現(xiàn)比較均衡的解決方案。

六、思考

對于此產(chǎn)品，還有可以持續(xù)完善的地方，比如：可以增加本地服務的?；钐结?，替代手動開啟代理規(guī)則，更智能化；或者利用其動態(tài)更新能力擴充功能，從很具體的小事情入手，不斷解決更多問題。

對于團隊，發(fā)現(xiàn)工作中的痛點，用工具化的方式沉淀解決方案，解決實際問題，也是前端同學提升自身價值的一個可行路徑。