JS 的执行细节
把 HTML 渲染到 webComponent 之后，我们就可以执行 JS 了
简单的实现
export function insertScriptToIframe( scriptResult: ScriptObject | ScriptObjectLoader, iframeWindow: Window, ) { const { content, // js 的代码字符串 } = scriptResult; const scriptElement = iframeWindow.document.createElement("script"); scriptElement.textContent = content || ""; // 获取 head 标签 const container = rawDocumentQuerySelector.call(iframeWindow.document, "head"); // 在 head 中插入 script 标签，就会运行 js container.appendChild(scriptElement); }
创建 script 标签，并插入到 iframe 的 head 中，就在 iframe 中能运行对应的 JS 代码。
这样虽然能运行 JS，但是产生的副作用（例如渲染的 UI），也会留在 iframe 中。
如何理解这句话？
当我们在 iframe 中，使用 document.querySelector查找 #app 的 DOM 时，它只能在 iframe 中查找（副作用留在 iframe 中），但 UI 是渲染到 webComponent 中的，webComponent 不在 iframe 中，且 iframe 不可见。
因此在 iframe 中就会找不到 DOM。
那要怎么办呢？
将 UI 渲染到 shadowRoot
我们先来看看现代的前端框架，是如何渲染 UI 的
以 Vue 为例，需要给 Vue 指定一个 DOM 作为挂载点，Vue 会将组件，挂载到该 DOM 上
import Comp from './comp.vue' // 传入根组件 const app = createApp(Comp) // 指定挂载点 app.mount('#app')
挂载到 #app，实际上使用 document.querySelector 查找 DOM，然后挂载到 DOM 里面
但是正如上一小节说的，在无界微前端会有问题：
- 如果在
iframe中运行document.querySelector，就会在iframe中查找就会查找不到，因为子应用的HTML是渲染到外部的shadowRoot的
因此这里必须要对 iframe 的 document.querySelector 进行改造，改为从 shadowRoot 里面查找，才能使 Vue 组件能够正确找到挂载点，伪代码如下：
const proxyDocument = new Proxy( {}, { get: function (_, propKey) { if (propKey === "querySelector" || propKey === "querySelectorAll") { // 代理 shadowRoot 的 querySelector/querySelectorAll 方法 return new Proxy(shadowRoot[propKey], { apply(target, ctx, args) { // 相当于调用 shadowRoot.querySelector return target.apply(shadowRoot, args); }, }); } }, } );
这样修改之后，调用 proxyDocument.querySelector 就会从 shadowRoot 中查找元素，就能挂载到 shadowRoot 中的 DOM 中了。
Vue 的根组件，就能成功挂载上去，其他子组件，因为是挂载到根节点或它的子节点上，不需要修改挂载位置，就能够正确挂载。
到此为止，如果不考虑其他 js 非视图相关的 js 代码，整个DOM 树就已经挂载成功，UI 就已经能够渲染出来了。
挟持 document 的属性/方法
上一小节，通过 proxyDocument.querySelector，就能从 shadowRoot 查找元素
但这样有一个坏处，就是要将 document 改成 proxyDocument，代码才能正确运行。但这是有方法解决的。
假如我们要运行的是以下代码：
const app = document.querySelector('#app') // do something
我们可以包一层函数：
(function (document){ const app = document.querySelector('#app') // do something })(proxyDocument)
这样就不需要修改子应用的源码，直接使用 document.querySelector
但是，这样做又会有新的问题：
- esModule 的 import 必须要在函数最外层
- var 声明的变量，原本是全局变量，包一层函数后，变量会被留在函数内
于是就有了下面的方案：
// 挟持 iframeWindow.Document.prototype 的 querySelector // 从 proxyDocument 中获取 Object.defineProperty(iframeWindow.Document.prototype, 'querySelector', { enumerable: true, configurable: true, get: () => sandbox.proxyDocument['querySelector'], set: undefined, });
只要我们在 iframe 创建时（子应用 JS），先通过 Object.defineProperty 重写 querySelector，挟持 document 的属性/方法，然后从 proxyDocument 中取值，
这样，就能直接执行子应用的 JS 代码，不需要另外包一层函数执行 JS
在无界微前端中，有非常多像 querySelector 的属性/方法，需要对每个属性方法的副作用进行修正。因此除了 proxyDocument，还有 proxyWindow、proxyLocation
很可惜的是，location 对象不能使用 Object.defineProperty 进行挟持，因此实际上，运行非 esModule 代码时，仍然需要用函数包一层运行，传入 proxyLocation 代替 location 对象。
但 esModule 由于不能在函数中运行，因此 esModule 代码中获取的 location 对象是错误的，这个无界的常见问题文档也有提到。
接下来稍微介绍一下无界对 DOM 和 iframe 副作用的一些处理
副作用的处理
无界通过创建代理对象、覆盖属性和函数等方式对原有的JavaScript对象进行挟持。需要注意的是，所有这些处理都必须在子应用 JS 运行之前，也就是在 iframe 创建时执行：
const iframe = window.document.createElement("iframe"); // 将 iframe 插入到 document 中 window.document.body.appendChild(iframe); const iframeWindow = iframe.contentWindow; // 停止 iframe 的加载 sandbox.iframeReady = stopIframeLoading(iframeWindow).then(() => { // 对副作用进行处理修正 }
在 stopIframeLoading 后，即停止 iframe 加载，获得纯净的 iframe 后，再对副作用进行处理
无界微前端 JS 有非常多的副作用需要修正处理，文章不会一一列举，这里会说一下大概，让大家对这个有点概念。
DOM 相关的副作用处理
下面是几个例子
修正相对 URl
<img src = "./images/test.png" alt = "Test Image" />
当我们在 DOM 中使用相对 url 时，会用 DOM 节点的 baseURI 作为基准，其默认值为 document.location.href。
但我们知道，子应用的 UI 是挂载在 shadowRoot，跟主应用是同一个 document 上下文，因此它的 baseURI 默认是主应用的 url，但实际上应该为子应用的 url 才对，因此需要修正。
下面是部分修正的伪代码：
// 重写 Node 原型的 appendChild，在新增 DOM 时修正 iframeWindow.Node.prototype.appendChild = function(node) { const res = rawAppendChild.call(this, node); // 修正 DOM 的 baseURI patchElementEffect(node, iframeWindow); return res; };
事实上，除了 appendChild，还有其他的函数需要修正，在每个能够创建 DOM 的位置，都需要进行修正，例如 insertBefore
修正 shadowRoot head、body
shadowRoot 可以视为子应用的 document
在前端项目中，经常会在 JS 中引入 CSS，实际上 CSS 文本会以 style 标签的形式注入到 docuement.head 中，伪代码如下：
export default function styleInject(css) { const head = document.head const style = document.createElement('style') style.type = 'text/css' style.styleSheet.cssText = css head.appendChild(style) }
在 iframe 中使用 document.head，需要用 Object.defineProperty 挟持 document 的 head 属性，将其重定向到 shadowRoot 的 head 标签
Object.defineProperty(iframeWindow.document, 'head', { enumerable: true, configurable: true, // 改为从 proxyDocument 中取值 get: () => sandbox.proxyDocument['head'], set: undefined, }); proxyDocument 的 head 实际上为 shadowRoot 的 head
shadowRoot.head = shadowRoot.querySelector("head"); shadowRoot.body = shadowRoot.querySelector("body");
同样的，很多组件库的弹窗，都会往 document.body 插入弹窗的 DOM，因此也要处理
iframe 的副作用处理
History API
history API 在 SPA 应用中非常常见，例如 vue-router 就会使用到 history.pushState、 history.replaceState 等 API。
当前 url 改变时
- 需要改变
document.baseURI，而它是个只读的值，需要修改document.head中的base标签 - 需要将子应用的 url，同步到父应用的地址栏中
history.pushState = function (data: any, title: string, url?: string): void { // 当前的 url const baseUrl = mainHostPath + iframeWindow.location.pathname + iframeWindow.location.search + iframeWindow.location.hash; // 根据当前 url，计算出即将跳转的 url 的绝对路径 const mainUrl = getAbsolutePath(url?.replace(appHostPath, ""), baseUrl); // 调用原生的 history.pushState rawHistoryPushState.call(history, data, title, ignoreFlag ? undefined : mainUrl); // 更新 head 中的 base 标签 updateBase(iframeWindow, appHostPath, mainHostPath); // 同步 url 到主应用地址栏 syncUrlToWindow(iframeWindow); };
window/document 属性/事件
有些属性，应该是使用主应用 window 的属性，例如：getComputedStyle
有些事件，需要挂载到主应用，有些需要挂载到 iframe 中。这里直接举个例子：
- onunload 事件，需要挂载到 iframe 中
- onkeyup 事件，需要挂载到主应用的 window 下（iframe 中没有 UI，UI 挂载到主应用 document 的 shadowRoot 下）
因此要挟持 onXXX 事件和 addEventListener，对每一个事件进行分发，将事件挂载到 window / iframeWindow 中
将事件挂载到window 的代码实现如下：
// 挟持 onXXX 函数 Object.defineProperty(iframeWindow, 'onXXX', { enumerable: true, configurable: true, // 从 window 取 get: () => window['onXXX'], set: (handler) => { // 设置到 window window['onXXX'] = typeof handler === "function" ? handler.bind(iframeWindow) // 将函数的 this 设置为 iframeWindow : handler; } });
通过 Object.defineProperty 挟持 onXXX，将事件设置到 window 上。
location 对象
当我们在子应用 iframe 中获取 location.href， location.host 等属性的时候，需要获取的是子应用的 href 和 host（iframe 的 location href 并不是子应用的 url），因此这里也是需要进行改造。
const proxyLocation = new Proxy( {}, { get: function (_, propKey) { if (propKey === "href") { return // 获取子应用真正的 url } // 省略其他属性的挟持 }, } );
为什么 iframe 的 location href 不是子应用的 url？
为了实现应用间（iframe 间）通讯，无界子应用 iframe 的 url 会设置为主应用的域名（同域）
总结
本文介绍了无界渲染子应用的步骤：
- 创建子应用 iframe
- 解析入口 HTML
- 创建 webComponent，并挂载 HTML
- 运行 JS 渲染 UI
最后介绍了无界是处理副作用的一些细节。
目前主流的微前端框架多多少少多会有些问题，目前还没有一种非常完美的方法实现微前端。即使是经历过长时间迭代的 qiankun，其设计上也有问题，因此还配有一个常见问题的页面，给开发者提供帮助去避免问题。
在本文中也介绍到，虽然无界的设计思想更为优秀，但其设计也是有局限性的，例如必须要允许跨域、location 对象无法挟持等，这些都是开发中会遇到的问题，只有理解了无界的设计，才能更好的理解这些问题的本质原因，以及知道如何去避免它们。
如果这篇文章对您有所帮助，可以点赞加收藏👍，您的鼓励是我创作路上的最大的动力。也可以关注我的公众号订阅后续的文章：Candy 的修仙秘籍（点击可跳转）
另外，想要米哈游/腾讯内推的，也可以关注公众号找我内推。
