微前端

微前端是什么

微前端是一种架构理念：将较大的前端应用拆分为若干个可以独立交付的子应用。在子应用内，只关注自己的业务需求。
这样的好处是：每个应用大小及复杂度相对可控。降低了应用之间的耦合度，提升每个团队的自治能力。

微前端方案通常需要考虑：应用加载机制、通信机制、代码隔离机制等问题。

微前端使用场景

• 如何渐进式地拥抱新技术
  应用技术栈老旧，重构和开发成本高。
  在开发新功能时，想要采用与老项目不同的技术栈，通过微前端的方案将新的功能与老系统进行集成。
• 大型系统的开发及沟通成本上升
  将系统拆分成多个独立子系统，使每个子系统能独立开发、运行及部署。
  避免随着需求的迭代，造成维护成本增大，跨部门沟通效率低下等问题。

微前端需要解决的核心问题

路由机制

一般,使用 Hash 或者 History 模式来对路由进行监听，对应的是 hashchange 或 popstate 事件。
目前，微前端解决方案主要是路由驱动的。
在微前端的基座，进行子应用的路由注册，如 { path: ‘/microA/*’ } ，
基座根据路由匹配情况，按需挂载子应用。
具体路由跳转规则由子应用接管响应。

隔离机制

需要支持css样式隔离和 JS 沙箱机制，以保证应用之间的样式或全局变量、事件等互不干扰。
对于新的项目，可以使用命名空间做样式隔离。
对于已有项目，可以在打包阶段利用工具自动对样式添加前缀。

实现 JS 沙箱机制可以采用快照的思路：
对进入子应用前的 Window 对象进行快照，用于后续卸载子应用时还原 Window 对象；
在卸载子应用时对 Window 对象进行快照，用于后续再次加载子应用时还原 Window 对象。

通信机制

合理划分应用，可以避免频繁的跨应用通信。
同时应当避免子应用之间直接通信。

常见的消息通信机制:

1. 自定义事件
   通过原生 CustomEvent 类实现，子应用通过 dispatchEvent 和 addEventListener 来对自定义事件进行下发和监听。
2. 借助 props
   通过主应用向子应用传参，达到通信目的

依赖机制

基座应用统一对子应用的状态进行管理。
根据路由和子应用状态，按需触发生命周期函数，做请求加载、渲染、卸载等动作。
而多个子应用间可能存在一些公共库的依赖。
为减少这类资源的重复加载，构建时应该进行公共依赖的配置，实现运行时依赖共享的能力。

iframe

iframe 常用于将应用嵌入另一个宿主应用中。这是一种微前端的思维。
只使用 iframe 方案引入子应用。
好处是：浏览器兼容性强，接入成本低，css及js天然隔离。
但是由于 iframe 和宿主应用完全隔离，各自独立运行，导致了诸多限制。
缺点：

1. 资源无法共享；
2. iframe 中的 UI 无法跨越 iframe 窗口边界；
3. 刷新页面时 iframe 中的路由状态丢失；

• 解决思路
  借助 ShadowRoot 渲染子应用的 DOM；
  eg.
  const shadowroot = element.attachShadow(shadowRootInit);
  iframe 负责运行子应用的 JavaScript 代码，
  从而实现 JS 沙箱和 CSS 隔离能力。
  另外，在保证子应用和主应用同源的前提下，将子应用的路由变化同步到主应用中，从而保证刷新页面后，路由地址正常。