微前端的实现方案

iframe 方案

特点

  • 接入比较简单
  • 隔离非常完美

不足

  • DOM割裂感严重，弹框只能在iframe内，且有滚动条
  • 通讯非常麻烦，而且刷新iframe url状态丢失
  • 前进后退按钮无效

qiankun 方案

qiankun 是基于 single-spa 的微前端方案。

特点

  • html entry 的方式引入子应用，相比 js entry 极大的降低了应用改造的成本
  • 完备的沙箱方案：
    • js 沙箱：SnapshotSandbox、LegacySandbox、ProxySandbox 三套渐进增强方案
    • css 沙箱：strictStyleIsolation、experimentalStyleIsolation 两套方案
  • 静态资源预加载能力

不足

  • 适配成本较高，工程化、生命周期、静态资源路径、路由等都要做适配
  • css 沙箱采用严格隔离会有各种问题
  • js 沙箱在某些场景下执行性能下降严重
  • 无法同时激活多个子应用，也不支持子应用保活
  • 无法支持 vite 等 esmodule 脚本运行

底层原理

底层原理 js沙箱使用的是proxy进行快照然后用用 with(window){} 包裹起来 with内的window其实就是 proxy.window
我们声明变量 var name = ‘777’ 实际这个变量挂到了proxy.window 并不是真正的window
css沙箱原理 第一个就是shadowDom隔离 第二个类似于Vue的scoped [data-qiankun-xxx]

micro-app 方案

micro-app 是基于 webcomponent + qiankun sandbox 的微前端方案。

特点

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

不足

  1. 接入成本较 qiankun 有所降低，但是路由依然存在依赖； （虚拟路由已解决）
  2. 多应用激活后无法保持各子应用的路由状态，刷新后全部丢失； （虚拟路由已解决）
  3. css 沙箱依然无法绝对的隔离，js 沙箱做全局变量查找缓存，性能有所优化；
  4. 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离；
  5. 对于不支持 webcompnent 的浏览器没有做降级处理；

底层原理

底层原理 js隔离跟qiankun类似也是使用proxy + with，css隔离自定义前缀类似于scoped

1
const prefix = `micro-app[name=${appName}]`

微前端的实现方案

EMP 方案

EMP 是基于 webpack 5 module federation 的微前端方案。

特点

  • webpack 联邦编译保证所有子应用依赖解耦
  • 应用间去中心化的调用、共享模块
  • 模块远程 ts 支持

不足

  • 对 webpack 强依赖
  • 没有有效的 css 沙箱和 js 沙箱
  • 子应用保活、多应用激活无法实现
  • 主、子应用的路由可能发生冲突

底层原理这个东西有点类似于拆包，也可以叫模块共享，例如React有个模块可以共享给Vue项目用Vue2的组件可以共享给Vue3用。

无界微前端方案

预览demo: WuJie-micro

特点

  • 接入简单只需要四五行代码
  • 不需要针对vite额外处理
  • 预加载
  • 应用保活机制

不足

  • 隔离js使用一个空的iframe进行隔离
  • 子应用axios需要自行适配
  • iframe沙箱初始化采用计时器等待不够优雅

底层原理 使用shadowDom 隔离css，js使用空的iframe隔离，通讯使用的是proxy