事件回顧：

收到需求，說是要在別人的系統(tǒng)里嵌入目前由我維護的系統(tǒng)，嵌入的邏輯不多，只有一個創(chuàng)建流程。

剛開始覺得沒什么，不就是你改改，我改改，你給我url加個參數(shù)，我知道是你調(diào)用，修改下頁面balabal。。。

奈何想法總是趕不上需求。

我要嵌入的頁面大概是這樣的↓↓↓。一共有三步,切換步驟不刷新頁面

要嵌入到對方的頁面大概如下↓↓↓。是在一個彈出的modal框里，第一步是對方的步驟，后三步由我們嵌入。

對方的需求：步驟條和下方控制按鈕放在他們頁面。跟我想的完全不一樣。于是開啟了這次旅程。

分析需求：

既然步驟條在對方頁面，那每一步就需要我們提供一個新的路由對應一個新頁面去展示，這很容易想到。但我們系統(tǒng)設(shè)計之初，這三步是一個連貫的操作，數(shù)據(jù)會向下流到最后一步才一次性提交給后端。而且下方控制下一步的按鈕放在對方頁面，所以就算我們提供新頁面也滿足不了需求。

不同路由不能滿足，那同一個路由不同hash呢？這里要感謝【守衛(wèi)】大哥，給了一個打開新世界的思路。

同一個路由改變hash值。頁面確實不會刷新。那么對方點擊下一步時，只要動態(tài)改變iframe的url hash，我們這里再監(jiān)聽hash值變化，事先約定好特定值，進而來回切換每一個步驟。嗯，似乎一切都是那么美好。但光想是不夠的。Task is cheap，show me the code。所以，我簡單模擬了一個iframe環(huán)境，嵌入我們系統(tǒng)的頁面。一切都很順利。但我忽略了一點。

這三步中的每一步不是想跳就跳的。每一步的表單都有校驗階段，校驗失敗我們肯定不會進行下一步。所以這就出現(xiàn)了一個問題：我們?nèi)绾瓮ㄖ疙撁姹卷撁嫘ｒ炿A段是否通過呢？因為步驟條在對方頁面，所以我們必須保證我們的實際步驟和對方的步驟條保持同步。

變更需求：

經(jīng)過一系列討論，我們決定找他們變更他們的需求。然而對方也很爽快，或許是因為對方不想在這個小需求上花太多時間，或許是因為我們這次是兩個人，氣勢十足。

最終決定步驟條和按鈕都可以放在我們頁面，但是最后一頁必須有一個返回按鈕來返回他們的頁面。

iframe里的按鈕如何改變?yōu)g覽器的路由呢？這里還要感謝【守衛(wèi)】大哥，真是字如其花名。提出a標簽的target屬性或許有幫助。點擊查看target的四種值及含義，這里不詳細講了。

a標簽target屬性的_top值可以使a標簽在iframe里改變?yōu)g覽器的路由。

至此，所有問題似乎以對方的妥協(xié)而告終。

但這不是架構(gòu)組的終點。

繼續(xù)思考：

現(xiàn)在的情況是：步驟條和按鈕都在我們頁面，就是說我們不需要做太多的修改，只需要在最后一個頁面加一個a標簽具有特定target值的屬性來改變?yōu)g覽器的URL，以此來實現(xiàn)關(guān)閉彈框modal并且返回到對方的列表頁。

這里有一個流暢度的問題。本來到第二步突然切換到iframe，頁面會有短時間空白，再加上最后一步跳回列表頁，又刷新了整個頁面，用戶體驗非常不好，我都感覺不好。

切換到iframe時的空白只能通過我們頁面的首屏性能優(yōu)化或者微前端的方式，但時間緊任務(wù)重。性能優(yōu)化和微前端不可能半天內(nèi)搞定，所以第二步優(yōu)化先放棄，那最后一步能不能優(yōu)化呢？

又想到了hash值。既然動態(tài)改變iframe url hash值不會導致iframe里頁面的刷新，那么我通過上方提到的a標簽來改變父頁面的hash值呢？貌似又發(fā)現(xiàn)了新大陸。

說干就干，找了兩個系統(tǒng)測試了一番，結(jié)果跟預想的一樣。

馬上通知對方開發(fā)人員，提出了這個方案，對方也欣然接受。

至此實現(xiàn)了最后一個步驟返回父頁面列表頁時，無感知關(guān)閉彈框modal。

上線后思考：

最后的方案雖然是步驟條和按鈕都在我們頁面，但根據(jù)上面提到的解決無感知關(guān)閉彈框的方案，步驟條和按鈕完全可以放到對方頁面，就像對方一開始提的需求一樣。

具體方案是：父頁面點擊下一步按鈕，改變子頁面hash值，子頁面監(jiān)聽hash值變化，走校驗邏輯。

校驗合格，通過代碼控制a標簽點擊來改變父頁面hash值，父頁面監(jiān)聽hash值變化，進而控制步驟條是否到下一步。

校驗不合格，則不改變父頁面hash值，則步驟條不動。

不過這種方式對于頁面原有hash值有侵入。我們兩個系統(tǒng)都沒有使用hash所以這個方式可行。對于那些原有頁面依賴hash展示的系統(tǒng)，這種方式并不適用。

小結(jié)：

iframe的父子頁面通信，除了postMessage等方式，相互改變hash值也是不錯的選擇。

父頁面通過JavaScript改變iframe的src的hash，同時監(jiān)聽自己的hash變化。

子頁面通過下方的方式改變父頁面的hash，同時監(jiān)聽自己的hash變化。

以此可以延伸到更多的場景。當父子頁面需要傳送很復雜的數(shù)據(jù)，可以把數(shù)據(jù)轉(zhuǎn)成字符串放到hash上。

注意：

hash變化會在歷史記錄生成一條數(shù)據(jù)，導致用戶回退時的頁面可能與預期不符，所以這個方式要視情況使用。

同時還要注意，hash功能本身是為了使瀏覽器能定位到頁面特定的元素↓↓↓

所以改變hash時要注意頁面上不能有有反應的元素。

總結(jié)

以上是生活随笔為你收集整理的iframe 覆盖父页面_一次iframe子页面与父页面的通信的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。