微前端（1）

本篇是微前端的学习记录。

概念

1. 微前端就是将一个大型前端应用拆分成多个模块（eg: 将项目根据业务模块拆分），每个模块可以由不同的团队进行管理，并可以自主选择框架、有自己的仓库，可以独立部署上线。
2. 主应用（基座）：主要负责集成所有的子应用，提供一个入口能访问你所需要的子应用。
   （1）一个系统只有一个
   （2）系统整体 Layout 的设计
   （3）所有微应用的配置与注册、路由映射、消息下发
   （4）尽量不写复杂业务逻辑
   微应用：根据不同业务划分的模块，每个子应用都打包成umd模块的形式供主应用来加载。
   （1）通常是一个单页面应用（SPA），负责具体的业务逻辑
   （2）可以独立交付（开发、部署、运行），但是一般会集成到主应用中运行
   （3）如有必要，甚至能集成到不同的主应用中

适用业务场景

1. 需要将多个后台系统统一收口的一个系统内。
2. 庞大的单页面应用，开发/构建时间长。
   微前端可以实现各个微应用的独立开发和发版，主应用管理微应用的注册和渲染，将整个系统彻底解耦。

思考：公司的业务场景偏向于1，UMS作为所有系统、用户、权限的管理，子系统的统一入口，适合作为主应用。各个子系统分管不同的业务（订单管理、出入库管理、售后管理、质量管理、产品追溯管理等），有各自的代码仓库和不同的开发特性，迭代周期也不同，适合作为微应用。
各个子系统与不同后端进行交互，可能会共享数据。

各实现方式对比

方案	具体实现	优点	不足
Nginx路由转发（服务端集成）	通过nginx代理来区分，同一个端口不同路由指向不同的前端项目，通讯可使用 sharedWorker。	简单	跨服务的组件无法嵌套，简单通讯可以使用会话存储，但需要比较复杂的封装，使用也不方便，有一层逻辑处理。适合业务分割清晰、跨服务组件之间关联少的项目，并且路由规划要严格。
iframe嵌套（运行时集成）	父应用单独是一个页面，每个子应用嵌套一个iframe，父子通信可采用postMessage或者contentWindow方式	子应用之间自带沙箱，天然隔离，互不影响	iframe样式显示（弹窗只在局部）、兼容性问题、刷新页面无法保存状态
Web Components	子应用使用纯Web Components编写	子应用拥有独立的script和css，也可以单独部署	改造成本高；子应用通信复杂
组合式应用路由分发	子应用独立构建和部署，运行时由父应用进行路由管理、应用加载、启动、卸载、通信	无感知切换体验良好，子应用相互隔离	父子应用处于同一页面，变量污染、通信问题

主要实现方式

路由分发

JavaScript的模块化来实现导入导出，可以使用importmap（eg: SystemJS），使变量名和其相应的地址一一映射，允许在非导入上下文中重用这个映射，避免重复书写地址。

隔离

css隔离： css Module或者namespace，可以采用webpack的postcss插件，在打包时添加特定的前缀；
js隔离：采用沙箱机制（局部的js运行不影响外部对象），对于浏览器需要结合with关键字和window.Proxy对象来实现。

通信

子应用之间不直接通信，采用消息订阅（pub/sub）模式，在基座应用中定义事件中心Event，子应用注册事件，当事件被触发时，事件中心统一分发。

生命周期

1. registerApplication：注册微应用
2. bootstrap：第一次挂载应用执行，只会被执行一次
3. mount：创建DOM节点，监听DOM事件，激活路由
4. unmount：卸载事件
5. unloaded
   其中bootstrap、mount、unmount必须由我们导出，否则会报错

Q & A

1. 主应用怎么加载微应用？
2. 主从通信？子应用之间通信？
3. 部署问题？

附录
京东
Single-Spa最早的微前端框架
微前端-最容易看懂的微前端知识
微前端究竟是什么？微前端核心技术揭秘！
微前端框架qiankun、ice比较
真的有必要用微前端框架么