什么是微前端？

将一个巨石应用的拆成一块块可控的小块应用的架构，就叫微前端。
当然，像我所在公司，也有因为多个独立的应用因不同业务团队维护，但业务方向是一致的，最后通过微前端来聚合成一个应用，方便用户访问。

为什么选择微前端？

1.技术栈无关
无论你是vue2、vue3、react、angular还是jquery，都能接入，不限制接入的子应用的技术栈。

2.渐进增量升级
打个比方，以vue2为技术栈的巨石项目的代码已经难以维护了（比如一个vue文件一两千行代码）
但我如果要重构这些代码，对它进行从vue2到vue3的技术栈的升级，将会耗费大量的精力和人力，十分痛苦。
如果我们要在此基础上进行迭代或者重构的话，我们可以采用将需要重构的部分进行升级，以重构部分作为子应用，把巨石项目作为基座的方式进行升级。
这样的话，我们就可以一步一步重构这些代码，最后再根据模块的划分，拆分成一个个应用，最后将应用聚合成一个项目。

3.独立部署
每个子应用都应具备有自己的持续交付流水线（包括构建、测试并部署到生产环境），不需要考虑其它子应用的状态。

怎么实现微前端？

方案一：iframe：每个微应用独立开发部署，通过 iframe的方式将这些应用嵌入到父应用系统中
优点：
1.天然的js、css隔离。
2.学习成本几乎为0。

缺点：
1.当子应用 url 跳转后，基座刷新，子应用 url 会丢失状态。导致没法保持路由状态。
2.iframe 会阻塞基座的 onload，导致全应用资源加载慢。
3.通信需要解决跨域问题，document.domain方法已被废弃。
4.子应用有弹窗组件，无法突破自身。
5.完全隔离导致与子应用交互难度很大。

方案二：qiankun
优点：
1.实现了js沙箱和css沙箱机制来实现隔离。
2.具有prefetch预加载机制，增强了用户体验。
3.基于single-spa进行封装，具备路由驱动的特性。

缺点：
1.如果使用shadowdom实现css沙箱隔离，想要获取子应用body，使用shadowRoot才能拿到。
2.公共依赖重复加载问题，多个子应用若有公共依赖，如组件库等，会导致加载多次。

方案三：npm构建集成，将微应用抽离成包的方式，发布Npm中，由父应用依赖的方式使用，构建时候集成进项目中
优点：
1.作用于编译时，运行时阶段无需加载。
2.开发与接入成本低，容易理解。

缺点：
1.全应用编译和打包速度、体积增大。
2.子应用更新后重新发布npm包，父应用也需要一起更新，导致需要两次打包部署，父应用和子应用强耦合。

方案四：webcomponent
优点：
1.结合shadowDom，将微前端应用抽象成一个类组件，大大降低对于应用的侵入性。
2.采用原生webcomponent实现，零依赖，框架十分轻便。

缺点：
1.shadowDom兼容性较差，webcomponent是浏览器新特性，缺少探索，可能需要踩坑。

【WIP..】

👾 浅谈微前端解决方案

什么是微前端？

为什么选择微前端？

怎么实现微前端？