微前端 ① 什么是微前端

什么是微前端

可以多团队，多框架共同构建 web 应用程序的技术。

微前端的价值

• 技术栈无关 主框架不限制接入应用的技术栈，子应用具备完全自主权
• 独立开发、独立部署 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
• 独立运行时 每个子应用之间状态隔离，运行时状态不共享

微前端场景解决方案

• 单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。通常基于 url 的变化来做子应用的切换。

• 多实例：同一时刻可展示多个子应用。通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。

最终目的是将不同框架，不同项目的中的页面或组件整合在指定的路由下同时展示，并能实现数据的隔离和消息的传递等。

架构实践

微前端正是将不同的框架和不同的项目整合在一个路由中，因此微前端框架的定位仅仅是 导航路由 + 资源加载框架。

Future State，一个基于前端路由的应用，整个应用可以看作是一个状态树，每一个分支都可以 lazy load, 在程序启动时，描述 lazy load 状态数分支的对象，就可以叫做 Future State。

当主应用导航到 https://a.com/subApp1 的时候子应用加载， 点击子应用的某个链接可能被导航到 https://a.com/subApp1/project，一个微前端框架应该能在路由匹配的时候加载子应用，路由不匹配的时候卸载子应用， 这就是 single-spa 做的工作。

应该用什么集成方式，主应用应该用何种资源形式加载子应用?, 一种方式是 JS Entry， 将子应用的资源打包为 js 资源，例如 single-spa 将要求将子应用打包为 systemJs 格式当作子应用入口, qiankun 要求将子应用打包为 umd 格式（考虑到应用需要独立部署）。另一种是 HTML Entry 直接使用子应用打包出的 html 文件当作入口，本质是解析 html 中引用的资源，因此也可以优化为直接使用资源描述的对象，以减少一次请求。

模块导入

singleSpa 采用 systemJs 的模块化方案，使用 singleSpa 提供的工具，默认只会编译出 js 文件，独立部署需要其他工具支持，通过 systemJs amd 扩展，可以避免将资源加载后添加的对象挂载到 windows 上。

qiankun 采用 umd 的模块化方案。需要使用 windows 快照的方式，获取到哪些对象被注入到 windows 中。

样式隔离方案

css-module，BEM 通过对 class 添加唯一标识保证唯一性。

css-in-js 代表库 emotion ，本质还是将样式转换为唯一的 class 类名，通过 style 标签插入。

shadowDom 浏览器严格隔离

singleSpa 并没有提供样式隔离方案，需要子应用单独处理。

qiankun 提供 experimentalStyleIsolation 配置， 本质上是给最外层元素样式添加唯一标识，相当于 css-module 实现方案，缺点是子应用中的元素如果挂载到了根节点外面会导致样式不生效。如果使用 strictStyleIsolation 配置，会使用 shadowDom 方案，缺点是主应用访问不到子应用的元素。另外，还实现了 Dynamic Stylesheet，原理是应用切出/卸载后，同时卸载掉其样式表，浏览器会对样式表的插入、移除做整个 CSSOM 的重构，因此保证只有一个应用的样式表是生效的，但是这种方式对于多实例的微前端场景无法处理。

js 隔离

singleSpa 并没有提供沙箱的实现， qiankun 实现了基于 Proxy 的多实例沙箱。

一个简单沙箱就是对 windows 快照， 当子应用卸载时，将 windows 对象回滚到之前的状态。

基于 Proxy 的单实例沙箱，创建 Proxy 对象，将对象的操作反映到 windows 的属性改变， 但是当多个子应用实例的时候，对同一属性的修改会导致 windows 属性混乱。

基于 Proxy 的多实例沙箱，不在对 windows 对象操作，直接

框架比较

• singleSpa 实现了最基本的路由功能，子应用加载功能。

• qiankuan 基于 singleSpa 的封装，实现了 css 隔离，以及 js 沙箱，保证应用状态隔离， 还提供了更多的特性：

  子应用并行，多个微前端同时存在
  子应用嵌套，微前端嵌套其他的微前端
  父子应用通讯
  预加载，空闲时加载子应用的资源
  公共依赖加载
  按需加载，切换到相应页面的时候才去加载资源