作者：damyxu，腾讯 PCG 前端开发工程师
iframe它是一种自然的微前端方案，但由于跨域的严格限制，不能很好地应用。本文介绍了一种基于它的方法 iframe 新的微前端方案，继承iframe的优点，补足 iframe 的缺点，让 iframe 焕发新生。
前端开发中我们对iframe已经很熟悉了，所以iframe它的作用是什么？可总结如下：
在一个web另一个可以在应用程序中独立运行web应用
与目前配置复杂、适应成本高的微前端方案相比，这一概念已经与微前端不谋而合。iframe该方案有一些显著的优点：
非常简单，无论是使用没有任何心理负担的完美隔离， js、css、dom 多应用激活完全隔离，页面可以放置多个iframe组合业务，但开发者讨厌使用iframe，缺点也很明显：
路由状态丢失，刷新，iframe 的 url 状态丢失dom 割裂严重，弹窗只能在 iframe 内部显示很难覆盖全局通信，只能通过 postmessage 传递序列化消息的白屏时间太长，对于SPA 应用应用来说无法接受能否打造一个完美的iframe，同时保留所有优点，解决所有缺点？
通过继承无界微前端框架iframe优点，解决iframe创造一个接近完美的缺点iframe方案。
看看无界是如何一步一步解决的iframe假设我们有问题 A 应用，想加载 B 应用：
在应用 A 中构造一个shadow和iframe，然后将应用 B 的html写入shadow中，js运行在iframe中，注意iframe的url，iframe保持与主应用同域但保留子应用的路径信息js可以运行在iframe的location和history保持正确的路由。
image-20211206160113792
在iframe中拦截document对象，统一将dom指向shadowRoot，例如，新元素、弹出窗口或泡沫组件可以正常限制shadowRoot内部。
下一步分别解决iframe三个缺点:
?
下一步分别解决iframe三个缺点:
? dom 主应用程序为严重分裂提供了一个容器shadowRoot插拔，shadowRoot内部弹出窗口也可以覆盖整个应用程序 A? 浏览器的前进和后退可以自然地影响路由状态丢失的问题iframe上，此时监听iframe如果浏览器刷新，路由变化并同步到主应用程序 url 读回保存的路由 很难通信，iframe和主应用是同域的，自然共享内存通信，无界提供分散的事件机制
包装这套机制wujie框架：
我们可以发现：
? 第一个白屏问题，wujie实例可以提前实例化，包括shadowRoot、iframe的创建、js实施，如此大的加速子应用的第一次开启时间 一旦切换的问题，一旦wujie例子可以缓存，子应用的切换成本变得非常低。如果采用保存模式，相当于shadowRoot的插拔
image-20211206160227875
由于子应用完全独立运行iframe内，路由依赖iframe的location和history，多个子应用程序也可以同时激活在一个页面上iframe与主应用相同top-level browsing context，因此，浏览器的前进和后退都可以作：
免费刷qq绿钻永久网址(有免费充黄钻和红钻·绿钻的网址吗？)
image-20211206160244704
无界方案可以通过述方法实现：
? 很简单，没有任何心理负担？ 很简单，没有任何心理负担？ 无论是什么，隔离都是完美的 js、css、dom 都完全隔离了 多应用激活可以放在页面上iframe组合业务路由状态丢失，刷新，iframe 的 url 状态丢失dom 裂缝严重，弹窗只能在 iframe 内部显示很难覆盖全局通信，只能通过 postmessage 传递序列化消息的白屏时间过长，对于SPA 如果主应用程序是不可接受的vue框架：
安装
引入
使用
其他框架也将在不久的将来上线
无限适配成本很低
主应用不需要任何改造
子应用：
前提，跨域配置必须开放，因为子应用是主应用域的要求和运行webpack应用，修改动态加载路径如果子应用保活模式则无需进一步修改，非保活则需要将实例化挂载到无界生命周期内子应用运行在一个和主应用同域的iframe中，设置src替换主域名host的子应用url，子应用路由只取location的pathname和hash
但是一旦设置src后，iframe由于同域，主应用程序将被加载html、js，所以必须在iframe实例化已完成，尚未加载html时中断加载，防止污染子应用
此时可采用轮询监听document.readyState对于一些浏览器，如safari状态不准确，可以在wujie主动抛错，防止主动应用js运行
子应用代码 code 在 iframe 内部访问 window，document、location 都被劫持到相应的地方 proxy，并注入$wujie对象供子应用调用
iframe 初始化内部副作用处理iframe主要分为以下几部分
ShadowRoot 必须处理内部副作用，主要的处理方法是shadowRoot的head和body
getOverwrittenAppendChildOrInsertBefore四种处理四种类型的标签：
link/style标签收集stylesheetElement用于子应用重新激活重建样式script动态插入标签script标签必须从ShadowRoot转移至iframe内部执行iframe标签修复iframe指向对应子应用iframe的window由于js在iframe运行需要和shadowRoot，包括元素创建、事件绑定等，将iframe的document进行劫持：
查询所有元素的所有代理shadowRoot内去查询head和body代理到shadowRoot的对应html元素上将iframe的location进行劫持：
由于iframe的url的host是主应用，所以需要将host改回子应用自己的location.href特殊逻辑的处理通过上面原理以及细节的阐述，我们可以得出无界微前端框架的几点优势：
多应用程序同时激活在线框架，同时激活多应用程序，并保持这些应用程序的路由同步能力。组件类型的使用不需要注册，更不用说路由适配了。跟随组件装卸的应用级别 keep-alive子应用程序打开保存模式后，整个子应用程序的状态可以在不丢失的情况下保存，结合预执行模式式可以结合预执行模式获得ssr开放体验纯净无污染，无限利用iframe和ShadowRoot建造自然js隔离沙箱和css使用隔离沙箱iframe的history和主应用的history在同一个top-level browsing context建造自然路由同步机制副作用局限在沙箱内部，子应用切换不需要任何清洁工作，没有额外的切换成本性能和体积，子应用执行性能与本地一致，子应用实例instance运行在iframe的window避免上下文with(proxyWindow){code}这样，指定代码执行上下文导致性能下降，但实例更多iframe一次性费用，可以通过proloadApp提前实例化包体积只有11kb，很轻，借助iframe和ShadowRoot为了实现沙箱，无论是风格兼容、路由处理、弹出窗口处理、热更新加载，都大大降低了代码量。子应用程序可以在没有额外处理的情况下打开，应用接入成本也很低，相应的不足: 内存占用率高。为了减少子应用的白屏时间，未激活子应用shadowRoot和iframe在常驻内存和保存模式下，每个页面都需要独一个wujie例如，内存成本大，兼容性一般，目前使用浏览器shadowRoot和proxy能力，而且没有降级计划iframe劫持document到shadowRoot有些第三方库可能不兼容，导致穿透
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时候联系我们修改或删除，多谢。
标签：
评论