微前端方案

https://www.yinaor.com/docs/front/micro/micro-solution

微前端方案​

iframe​

使用 iframe 其实就可以做到多个子应用放到一个主应用的效果，但是有优点也有缺点：

• 非常简单，使用没有任何心智负担
• web应用隔离的非常完美，无论是js、css、dom都完全隔离开来

• 路由状态丢失，刷新一下，iframe的url状态就丢失了
• dom割裂严重，弹窗只能在iframe内部展示，无法覆盖全局
• web应用之间通信非常困难
• 每次打开白屏时间太长，对于SPA 应用来说无法接受

qiankun​

single-spa是一个目前主流的微前端技术方案，其主要实现思路：

• 预先注册子应用(激活路由、子应用资源、生命周期函数)
• 监听路由的变化，匹配到了激活的路由则加载子应用资源，顺序调用生命周期函数（bootstrap、mount、unmount，分别对应初始化、渲染和卸载）并最终渲染到容器

乾坤微前端架构则进一步对 single-spa 方案进行完善，主要的完善点：

• 子应用资源由 js 列表修改进为一个 url，大大减轻注册子应用的复杂度
• 实现应用隔离，完成 js 隔离方案 （window 工厂、proxy、with(window){}） 和 css 隔离方案 （shadowDom、类 vue 的 scoped）
• 增加资源预加载能力，预先子应用 html、js、css 资源缓存下来，加快子应用的打开速度

• 监听路由自动的加载、卸载当前路由对应的子应用
• 完备的沙箱方案，js沙箱做了SnapshotSandbox、LegacySandbox、ProxySandbox三套渐进增强方案，css沙箱做了两套strictStyleIsolation、experimentalStyleIsolation两套适用不同场景的方案
• 路由保持，浏览器刷新、前进、后退，都可以作用到子应用
• 应用间通信简单，全局注入

• 基于路由匹配，无法同时激活多个子应用，也不支持子应用保活
• 改造成本较大，从 webpack、代码、路由等等都要做一系列的适配
• css 沙箱无法绝对的隔离，js 沙箱在某些场景下执行性能下降严重
• 无法支持 vite 等 ESM 脚本运行

micro-app​

micro-app 是基于 webcomponent + qiankun sandbox 的微前端方案，号称是目前市面上接入微前端成本最低的方案。

micro-app 并没有沿袭 single-spa 的思路，而是借鉴了 WebComponent 的思想，通过 CustomElement 结合自定义的 ShadowDom，将微前端封装成一个类 WebComponent 组件，从而实现微前端的组件化渲染。

并且由于自定义 ShadowDom 的隔离特性，micro-app 不需要像 single-spa 和 qiankun 一样要求子应用修改渲染逻辑并暴露出方法，也不需要修改 webpack 配置。

• 使用 webcomponet 加载子应用相比 single-spa 这种注册监听方案更加优雅
• 复用经过大量项目验证过 qiankun 的沙箱机制也使得框架更加可靠
• 组件式的 api 更加符合使用习惯，支持子应用保活
• 降低子应用改造的成本，提供静态资源预加载能力

• css 沙箱依然无法绝对的隔离
• 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离
• 对于不支持 webcompnent 的浏览器没有做降级处理

无界​

官网列出了无界方案的详细介绍：

应用加载机制和 js 沙箱机制​

将子应用的 js 注入主应用同域的 iframe 中运行，iframe 是一个原生的 window 沙箱，内部有完整的 history 和 location 接口，子应用实例 instance 运行在 iframe 中，路由也彻底和主应用解耦，可以直接在业务组件里面启动应用。

路由同步机制​

在 iframe 内部进行 history.pushState，浏览器会自动的在 joint session history 中添加 iframe 的 session-history，浏览器的前进、后退在不做任何处理的情况就可以直接作用于子应用

劫持 iframe 的 history.pushState 和 history.replaceState，就可以将子应用的 url 同步到主应用的 query 参数上，当刷新浏览器初始化 iframe 时，读回子应用的 url 并使用 iframe 的 history.replaceState 进行同步

iframe 连接机制和 css 沙箱机制​

无界采用 webcomponent 来实现页面的样式隔离，无界会创建一个 wujie 自定义元素，然后将子应用的完整结构渲染在内部

子应用的实例 instance 在 iframe 内运行，dom 在主应用容器下的 webcomponent 内，通过代理 iframe 的 document 到 webcomponent，可以实现两者的互联。

将 document 的查询类接口：getElementsByTagName、getElementsByClassName、getElementsByName、getElementById、querySelector、querySelectorAll、head、body 全部代理到 webcomponent，这样 instance 和 webcomponent 就精准的链接起来。

当子应用发生切换，iframe 保留下来，子应用的容器可能销毁，但 webcomponent 依然可以选择保留，这样等应用切换回来将 webcomponent 再挂载回容器上，子应用可以获得类似 vue 的 keep-alive 的能力.

通信机制​

承载子应用的 iframe 和主应用是同域的，所以主、子应用天然就可以很好的进行通信，在无界我们提供三种通信方式

1. props 注入机制 子应用通过 $wujie.props 可以轻松拿到主应用注入的数据
2. window.parent 通信机制 子应用 iframe 沙箱和主应用同源，子应用可以直接通过 window.parent 和主应用通信
3. 去中心化的通信机制 无界提供了 EventBus 实例，注入到主应用和子应用，所有的应用可以去中心化的进行通信

• 多应用同时激活在线 框架具备同时激活多应用，并保持这些应用路由同步的能力
• 组件式的使用方式 无需注册，更无需路由适配，在组件内使用，跟随组件装载、卸载
• 应用级别的 keep-alive 子应用开启保活模式后，应用发生切换时整个子应用的状态可以保存下来不丢失，结合预执行模式可以获得类似 ssr 的打开体验
• 纯净无污染
  • 无界利用 iframe 和 webcomponent 来搭建天然的 js 隔离沙箱和 css 隔离沙箱
  • 利用 iframe 的 history 和主应用的 history 在同一个 top-level browsing context 来搭建天然的路由同步机制
  • 副作用局限在沙箱内部，子应用切换无需任何清理工作，没有额外的切换成本
• 性能和体积兼具
  • 子应用执行性能和原生一致，子应用实例 instance 运行在 iframe 的 window 上下文中，避免 with(proxyWindow){code} 这样指定代码执行上下文导致的性能下降，但是多了实例化 iframe 的一次性的开销，可以通过 preload 提前实例化
  • 体积比较轻量，借助 iframe 和 webcomponent 来实现沙箱，有效的减小了代码量
• 开箱即用 不管是样式的兼容、路由的处理、弹窗的处理、热更新的加载，子应用完成接入即可开箱即用无需额外处理，应用接入成本也极低