為iframe正名，你可能并不需要微前端

當前位置：點晴教程→知識管理交流 →『技術文檔交流』

freeflydom

2023年5月30日 10:10 本文熱度 579

阿里巴巴終端技術 2023年01月05日

作者：劉顯安(碼怪)

任何新技術、新產品都是有一定適用場景的，它可能在當下很流行，但它不一定在任何時候都是最優解。

前言

最近幾年微前端很火，火到有時候項目里面用到了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毫秒地址欄才會更新，有點美中不足?？梢园训刂窓诘母略凇疤D后”基礎之上再加一個“跳轉前”。為此我們必須有一個全局的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': 'https://fs.alibaba.com/xxx/home.htm?hideLayout=1',
    '/fin/apply.html': 'https://fs.alibaba.com/xxx/apply?hideLayout=1',
    '/fin/failed.html': 'https://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 = [
    'https://service.alibaba.com/',
    'https://sale.alibaba.com/xxx/',
    'https://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 = `https://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天時間即可完成，最重要的是大部分工作都是全局生效的，不會隨著頁面的增多而導致工作量增加，測試回歸的成本也非常低，只需要驗證所有頁面跳轉、展示等是否正常，功能本身一般不會有太大問題，而如果是微前端方案的話需要從頭到尾全部仔仔細細測試一遍，開發和測試的成本都不可估量。

————————————————————

https://juejin.cn/post/7185070739064619068

該文章在 2023/5/30 10:34:46 編輯過

關鍵字查詢

可能

不需要

正在查詢...

點晴ERP是一款針對中小制造業的專業生產管理軟件系統,系統成熟度和易用性得到了國內大量中小企業的青睞。

點晴PMS碼頭管理系統主要針對港口碼頭集裝箱與散貨日常運作、調度、堆場、車隊、財務費用、相關報表等業務管理，結合碼頭的業務特點，圍繞調度、堆場作業而開發的。集技術的先進性、管理的有效性于一體，是物流碼頭及其他港口類企業的高效ERP管理信息系統。

點晴WMS倉儲管理系統提供了貨物產品管理,銷售管理,采購管理,倉儲管理,倉庫管理,保質期管理,貨位管理,庫位管理,生產管理,WMS管理系統,標簽打印,條形碼,二維碼管理,批號管理軟件。

點晴免費OA是一款軟件和通用服務都免費，不限功能、不限時間、不限用戶的免費OA協同辦公管理系統。

狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

為iframe正名，你可能并不需要微前端

前言

優缺點分析

iframe適合的場景

實戰：A系統接入B系統

隱藏原系統導航菜單

前進后退處理

URL的同步更新

什么時候更新URL地址

優化URL的更新速度

美化URL地址

全局跳轉攔截

服務端跳轉攔截

A標簽跳轉攔截

location.href攔截

window.open攔截

history.pushState攔截

history.replaceState攔截

全局loading處理

彈窗居中問題

最終效果

結語

為iframe正名，你可能并不需要微前端