為iframe正名，你可能並不需要微前端
作者：劉顯安(碼怪)
任何新技術、新產品都是有一定適用場景的，它可能在當下很流行，但它不一定在任何時候都是最優解。
前言
最近幾年微前端很火，火到有時候專案裡面用到了iframe還要偷偷摸摸地藏起來生怕被別人知道了，因為擔心被人質疑：你為什麼不用微前端方案？直到最近筆者接手一個專案，需要將現有的一個系統整體嵌入到另外一個系統（一共20多個頁面），在被微前端坑了幾次之後，回過頭髮現，iframe真香！
qiankun的作者有一篇《Why Not Iframe》 介紹了iframe的優缺點（不過作者還有一篇《你可能並不需要微前端》給微前端降降火），誠然iframe確實存在很多缺點，但是在選擇一個方案的時候還是要具體場景具體分析，它可能在當下很流行，但它不一定在任何時候都是最優解：iframe的這些缺點對我來說是否能夠接受？它的缺點是否有其它方法可以彌補？使用它到底是利大於弊還是弊大於利？我們需要在優缺點之間找到一個平衡。
優缺點分析
iframe適合的場景
由於iframe的一些限制，部分場景並不適合用iframe，比如像下面這種iframe只佔據頁面中間部分割槽域，由於父頁面已經有一個滾動條了，為了避免出現雙滾動條，只能動態計算iframe的內容高度賦值給iframe，使得iframe高度完全撐滿，但這樣帶來的問題是彈窗很難處理，如果居中的話一般彈窗都相對的是iframe內容高度而不是螢幕高度，從而導致彈窗可能看不見，如果固定彈窗top又會導致彈窗跟隨頁面滾動，而且稍有不慎iframe內容高度計算有一點點偏差就會出現雙滾動條。
所以：
- 如果頁面本身比較簡單，是一個沒有彈窗、浮層、高度也是固定的純資訊展示頁的話，用iframe一般沒什麼問題；
- 如果頁面是包含彈窗、資訊提示、或者高度不是固定的話，需要看iframe是否佔據了全部的內容區域，如果是像下圖這種經典的導航+選單+內容結構、並且整個內容區域都是iframe，那麼可以放心大膽地嘗試iframe，否則，需要慎重考慮方案選型。
為什麼一定要滿足“iframe佔據全部內容區域”這個條件呢？可以想象一下下面這種場景，滾動條出現在頁面中間應該大部分人都無法接受：
實戰：A系統接入B系統
滿足“iframe佔據全部內容區域”條件的場景，iframe的幾個缺點都比較好解決。下面通過一個實際案例來詳細介紹將一個線上在執行的系統接入到另外一個系統的全過程。以筆者前段時間剛完成的ACP（全稱Alibaba.com Pay，阿里巴巴國際站旗下一站式全球收款平臺，下稱A系統）接入生意貸（下稱B系統）為例，已知：
- ACP和生意貸都是MPA頁面；
- ACP系統在此之前沒有接入其他系統的先例，生意貸是第一個；
- 生意貸作為被接入系統，本次需要接入的一共有20多個頁面，且服務端包含大量業務邏輯以及跳轉控制，有些頁面想看看長什麼樣子都非常困難，需要在Node層mock大量介面；
- 接入時需要做功能刪減，部分介面入參需要調整；
- 生意貸除了接入到ACP系統中，之前還接入過AMES系統，本次接入需要相容這部分歷史邏輯；
我們希望的效果：
假設我們新增一個頁面 /fin/base.html?entry=xxx 作為我們A系統承接B系統的地址，A系統有類似如下程式碼：
class App extends React.Component {
state = {
currentEntry: decodeURIComponent(iutil.getParam('entry') || '') || '',
};
render() {
return <div>
<iframe id="microFrontIframe" src={this.state.currentEntry}/>
</div>;
}
}
隱藏原系統導航選單
因為是接入到另外一個系統，所以需要將原系統的選單和導航等都通過一個類似“hideLayout”的引數去隱藏。
前進後退處理
需要特別注意的是，iframe頁面內部的跳轉雖然不會讓瀏覽器位址列發生變化，但是卻會產生一個看不見的“history記錄”，也就是點選前進或後退按鈕（history.forward()或history.back()）可以讓iframe頁面也前進後退，但是位址列無任何變化。
所以準確來說前進後退無需我們做任何處理，我們要做的就是讓瀏覽器位址列同步更新即可。
如果要禁用瀏覽器的上述預設行為，一般只能在iframe跳轉時通知父頁面更新整個
<iframe />DOM節點。
URL的同步更新
讓URL同步更新需要處理2個問題，一個是什麼時候去觸發更新的動作，一個是URL更新的規律，即父頁面的URL地址（A系統）與iframe的URL地址（B系統）對映關係的維護。
保證URL同步更新功能正常需要滿足這3種情況：
- case1: 頁面重新整理，iframe能夠載入正確頁面；
- case2: 頁面跳轉，瀏覽器位址列能夠正確更新；
- case3: 點選瀏覽器的前進或後退，位址列和iframe都能夠同步變化；
什麼時候更新URL地址
首先想到的肯定是在iframe載入完傳送一個通知給父頁面，父頁面通過history.replaceState去更新URL。
為什麼不是
history.pushState呢？因為前面提到過，瀏覽器預設會產生一條歷史記錄，我們只需要更新地址即可，如果用pushState會產生2條記錄。
B系統：
<script>
var postMessage = function(type, data) {
if (window.parent !== window) {
window.parent.postMessage({
type: type,
data: data,
}, '*');
}
}
// 為了讓URL地址儘早地更新，這段程式碼需要儘可能前置，例如可以直接放在document.head中
postMessage('afterHistoryChange', { url: location.href });
</script>
A系統：
window.addEventListener('message', e => {
const { data, type } = e.data || {};
if (type === 'afterHistoryChange' && data?.url) {
// 這裡先採用一個兜底的URL承接任意地址
const entry = `/fin/base.html?entry=${encodeURIComponent(data.url)}`;
// 地址不一樣才需要更新
if (location.pathname + location.search !== entry) {
window.history.replaceState(null, '', entry);
}
}
});
優化URL的更新速度
按照上面的方法實現後可以發現，URL雖然可以更新但是速度有點慢，點選跳轉後一般需要等待7-800毫秒位址列才會更新，有點美中不足。可以把位址列的更新在“跳轉後”基礎之上再加一個“跳轉前”。為此我們必須有一個全域性的beforeRedirect鉤子，先不考慮它的具體實現：
B系統：
function beforeRedirect(href) {
postMessage('beforeHistoryChange', { url: href });
}
A系統：
window.addEventListener('message', e => {
const { data, type } = e.data || {};
if ((type === 'beforeHistoryChange' || type === 'afterHistoryChange') && data?.url) {
// 這裡先採用一個兜底的URL承接任意地址
const entry = `/fin/base.html?entry=${encodeURIComponent(data.url)}`;
// 地址不一樣才需要更新
if (location.pathname + location.search !== entry) {
window.history.replaceState(null, '', entry);
}
}
});
加上上述程式碼之後，點選iframe中的跳轉連結，URL會實時更新，瀏覽器的前進後退功能也正常。
為什麼需要同時保留跳轉前和跳轉後呢？因為如果只保留跳轉前，只能滿足前面的case1和case2，case3無法滿足，也就是點選後退按鈕只有iframe會後退，URL地址不會更新。
美化URL地址
簡單的使用/fin/base.html?entry=xxx這樣的通用地址雖然能用，但是不太美觀，而且很容易被人看出來是iframe實現的，比較沒有誠意，所以如果被接入系統的頁面數量在可列舉範圍內，建議給每個地址維護一個新的短地址。
首先，新增一個SPA頁面/fin/*.html，和前面的/fin/base.html指向同一個頁面，然後維護一個URL地址的對映，類似這樣：
// A系統地址到B系統地址對映
const entryMap = {
'/fin/home.html': 'http://fs.alibaba.com/xxx/home.htm?hideLayout=1',
'/fin/apply.html': 'http://fs.alibaba.com/xxx/apply?hideLayout=1',
'/fin/failed.html': 'http://fs.aibaba.com/xxx/failed?hideLayout=1',
// 省略
};
const iframeMap = {}; // 同時再維護一個子頁面 -> 父頁面URL對映
for (const entry in entryMap) {
iframeMap[entryMap[entry].split('?')[0]] = entry;
}
class App extends React.Component {
state = {
currentEntry: decodeURIComponent(iutil.getParam('entry') || '') || entryMap[location.pathname] || '',
};
render() {
return <div>
<iframe id="microFrontIframe" src={this.state.currentEntry}/>
</div>;
}
}
同時完善一下更新URL地址部分：
// base.html繼續用作兜底
let entry = `/fin/base.html?entry=${encodeURIComponent(data.url)}`;
const [path, search] = data.url.split('?');
if (iframeMap[path]) {
entry = `${iframeMap[path]}?${search || ''}`;
}
// 地址不一樣才需要更新
if (location.pathname + location.search !== entry) {
window.history.replaceState(null, '', entry);
}
省略引數透傳部分程式碼。
全域性跳轉攔截
為什麼一定要做全域性跳轉攔截呢？一個因為我們需要把hideLayout引數一直透傳下去，否則就會點著點著突然出現下面這種雙選單的情況：
另一個是有些頁面在被嵌入前是當前頁面開啟的，但是被嵌入後不能繼續在當前iframe開啟，比如支付寶付款這種第三方頁面，想象一下下面這種情況會不會覺得很怪？所以這類頁面一定要做特殊處理讓它跳出去而不是當前頁面開啟。
URL跳轉可以分為服務端跳轉和瀏覽器跳轉，瀏覽器跳轉又包括A標籤跳轉、location.href跳轉、window.open跳轉、historyAPI跳轉等；
而根據是否新標籤開啟又可以分為以下4種場景：
- 繼續當前iframe開啟，需要隱藏原系統的所有layout；
- 當前父頁面開啟第三方頁面，不需要任何layout；
- 新開標籤開啟第三方頁面（如支付寶頁面），不需要做特殊處理；
- 新開標籤開啟宿主頁面，需要把原系統layout替換成新layout；
為此，先定義好一個beforeRedirect方法，由於新標籤開啟有target="_blank"和window.open等方式，父頁面開啟有target="_parent"和window.parent.location.href等方式，為了更好的統一封裝，我們把特殊情況的跳轉統一在beforeRedirect處理好，並約定只有有返回值的情況才需要後續繼續處理跳轉：
// 維護一個需要做特殊處理的第三方頁面列表
const thirdPageList = [
'http://service.alibaba.com/',
'http://sale.alibaba.com/xxx/',
'http://alipay.com/xxx/',
// ...
];
/**
* 封裝統一的跳轉攔截鉤子，處理引數透傳和一些特殊情況
* @param {*} href 要跳轉的地址，允許傳入相對路徑
* @param {*} isNewTab 是否要新標籤開啟
* @param {*} isParentOpen 是否要在父頁面開啟
* @returns 返回處理好的跳轉地址，如果沒有返回值則表示不需要繼續處理跳轉
*/
function beforeRedirect(href, isNewTab) {
if (!href) {
return;
}
// 傳過來的href可能是相對路徑，為了做統一判斷需要轉成絕對路徑
if (href.indexOf('http') !== 0) {
var a = document.createElement('a');
a.href = href;
href = a.href;
}
// 如果命中白名單
if (thirdPageList.some(item => href.indexOf(item) === 0)) {
if (isNewTab) {
// _rawOpen參見後面 window.open 攔截
window._rawOpen(href);
} else {
// 第三方頁面如果不是新標籤開啟就一定是父頁面開啟
window.parent.location.href = href;
}
return;
}
// 需要從當前URL繼續往下透傳的引數
var params = ['hideLayout', 'tracelog'];
for (var i = 0; i < params.length; i++) {
var value = getParam(params[i], location.href);
if (value) {
href = setParam(params[i], value, href);
}
}
if (isNewTab) {
let entry = `/fin/base.html?entry=${encodeURIComponent(href)}`;
const [path, search] = href.split('?');
if (iframeMap[path]) {
entry = `${iframeMap[path]}?${search || ''}`;
}
href = `http://payment.alibaba.com${entry}`;
window._rawOpen(href);
return;
}
// 如果是以iframe方式嵌入，向父頁面傳送通知
postMessage('beforeHistoryChange', { url: href });
return href;
}
服務端跳轉攔截
服務端主要是對301或302重定向跳轉進行攔截，以Egg為例，只要重寫 ctx.redirect 方法即可。
A標籤跳轉攔截
document.addEventListener('click', function (e) {
var target = e.target || {};
// A標籤可能包含子元素，點選目標可能不是A標籤本身，這裡只簡單判斷2層
if (target.tagName === 'A' || (target.parentNode && target.parentNode.tagName === 'A')) {
target = target.tagName === 'A' ? target : target.parentNode;
var href = target.href;
// 不處理沒有配置href或者指向JS程式碼的A標籤
if (!href || href.indexOf('javascript') === 0) {
return;
}
var newHref = beforeRedirect(href, target.target === '_blank');
// 沒有返回值一般是已經處理了跳轉，需要禁用當前A標籤的跳轉
if (!newHref) {
target.target = '_self';
target.href = 'javascript:;';
} else if (newHref !== href) {
target.href = newHref;
}
}
}, true);
location.href攔截
location.href攔截至今是一個困擾前端界的難題，這裡只能採用一個折中的方法：
// 由於 location.href 無法重寫，只能實現一個 location2.href = ''
if (Object.defineProperty) {
window.location2 = {};
Object.defineProperty(window.location2, 'href', {
get: function() {
return location.href;
},
set: function(href) {
var newHref = beforeRedirect(href);
if (newHref) {
location.href = newHref;
}
},
});
}
因為我們不僅實現了location.href的寫，location.href的讀也一起實現了，所以可以放心大膽的進行全域性替換。找到對應前端工程，首先全域性搜尋window.location.href，批量替換成(window.location2 || window.location).href，然後再全域性搜尋location.href，批量替換成(window.location2 || window.location).href（思考一下為什麼一定是這個順序呢）。
另外需要注意，有些跳轉可能是寫在npm包裡面的，這種情況只能npm也跟著替換一下了，並沒有其它更好辦法。
window.open攔截
var tempOpenName = '_rawOpen';
if (!window[tempOpenName]) {
window[tempOpenName] = window.open;
window.open = function(url, name, features) {
url = beforeRedirect(url, true);
if (url) {
window[tempOpenName](url, name, features);
}
}
}
history.pushState攔截
var tempName = '_rawPushState';
if (!window.history[tempName]) {
window.history[tempName] = window.history.pushState;
window.history.pushState = function(state, title, url) {
url = beforeRedirect(url);
if (url) {
window.history[tempName](state, title, url);
}
}
}
history.replaceState攔截
var tempName = '_rawReplaceState';
if (!window.history[tempName]) {
window.history[tempName] = window.history.replaceState;
window.history.replaceState = function(state, title, url) {
url = beforeRedirect(url);
if (url) {
window.history[tempName](state, title, url);
}
}
}
全域性loading處理
完成上述步驟後，基本上已經看不出來是iframe了，但是跳轉的時候中間有短暫的白屏會有一點頓挫感，體驗不算很流暢，這時候可以給iframe加一個全域性的loading，開始跳轉前顯示，頁面載入完再隱藏：
B系統：
document.addEventListener('DOMContentLoaded', function (e) {
postMessage('iframeDOMContentLoaded', { url: location.href });
});
A系統：
window.addEventListener('message', (e) => {
const { data, type } = e.data || {};
// iframe 載入完畢
if (type === 'iframeDOMContentLoaded') {
this.setState({loading: false});
}
if (type === 'beforeHistoryChange') {
// 此時頁面並沒有立即跳轉，需要再稍微等待一下再顯示loading
setTimeout(() => this.setState({loading: true}), 100);
}
});
除此之外還需要利用iframe自帶的onload加一個兜底，防止iframe頁面沒有上報 iframeDOMContentLoaded 事件導致loading不消失：
// iframe自帶的onload做兜底
iframeOnLoad = () => {
this.setState({loading: false});
}
render() {
return <div>
<Loading visible={this.state.loading} tip="正在載入..." inline={false}>
<iframe id="microFrontIframe" src={this.state.currentEntry} onLoad={this.iframeOnLoad}/>
</Loading>
</div>;
}
還需要注意，當新標籤頁開啟頁面時並不需要顯示loading，需要注意區分。
彈窗居中問題
當前場景下彈窗個人覺得並不需要處理，因為選單的寬度有限，不仔細看的話甚至都沒注意到彈窗沒有居中：
如果非要處理的話也不麻煩，覆蓋一下原來頁面彈窗的樣式，當包含hideLayout引數時，讓彈窗的位置分別向左移動menuWidth/2、向上移動navbarHeight/2即可（遮罩位置不能動、也動不了）。
添加了marginLeft=-120px、marginTop=-30px 後的彈窗效果：
最終效果
其實不難看出，最終效果和SPA幾乎無異，而且選單和導航本來就是無重新整理的，頁面跳轉沒有割裂感：
結語
上述方案有幾個沒有提到的點：
- 方案成立的前提是建立在2個系統共用一套使用者體系，否則需要對2個系統的登入體系進行打通，一般包括賬號繫結、A系統預設免登B系統，等等，這需要一定額外的工作量；
- 引數的透傳與刪除，例如我希望除了hideLayout引數之外其它URL引數全部在父子頁面之間透傳；
- 埋點，資料上報的時候需要增加一個額外引數來標識流量來自另外一個系統；
在第一次摸索方案時可能需要花費一些時間，但是在熟悉之後，如果後續還有類似把B系統接入A系統的需求，在沒有特殊情況且順利的前提下可能花費1-2天時間即可完成，最重要的是大部分工作都是全域性生效的，不會隨著頁面的增多而導致工作量增加，測試迴歸的成本也非常低，只需要驗證所有頁面跳轉、展示等是否正常，功能本身一般不會有太大問題，而如果是微前端方案的話需要從頭到尾全部仔仔細細測試一遍，開發和測試的成本都不可估量。
- 為iframe正名，你可能並不需要微前端
- SLS：基於 OTel 的移動端全鏈路 Trace 建設思考和實踐
- 為iframe正名，你可能並不需要微前端
- 釘釘 ANR 治理最佳實踐 | 定位 ANR 不再霧裡看花
- 釘釘 ANR 治理最佳實踐 | 定位 ANR 不再霧裡看花
- 低程式碼多分支協同開發的建設與實踐
- Flutter for Web 首次首屏優化——JS 分片優化
- 全新的 React 元件設計理念 Headless UI
- 我們是如何追逐元宇宙、XR等“概念股”浪潮的？
- 盒馬 iOS Live Activity &“靈動島”配送場景實踐
- ECMAScript 雙月報告：Hashbang Grammer 提案成功進入到 Stage 4
- 如何根治 Script Error.
- 語雀桌面端技術架構實踐
- 語雀桌面端技術架構實踐
- Clang Module 內部實現原理及原始碼分析
- 基於 LowCodeEngine 的除錯能力建設與實踐
- 基於 LowCodeEngine 的除錯能力建設與實踐
- Android Target 31 升級全攻略 —— 記阿里首個超級 App 的坎坷升級之路