我对微前端的一些理解

最近要开发的项目中需要用到微前端的内容，所以对微前端做了一些调研，并且总结了一些自己的理解，以问题&答案的形式展示给各位：

什么是微前端？

摘取了两种自己比较认可的说法：

1.一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。
2.微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。

 

通俗点讲就是多个不限制技术栈的前端应用可以组合在一起构建成最终需要的系统（类似于多个组件组成页面一样）

为什么会出现微前端？

1.中心化的配置有可能会“牵一发而动全身”，例如route.js、webpack配置等。
2.以企业级 Web 应用为典型的长周期项目，最终会演变为一个巨大且杂乱的项目，打包体积大，启动时间长
3.传统应用对多个团队之间的配合度要求较高，团队之间的耦合度较高。例如需要使用相同的技术栈，一个团队的开发可能受限于其他团队的进度

微前端的优点？

(摘自qiankun官方文档)

1.技术栈无关 主框架不限制接入应用的技术栈，子应用具备完全自主权（important）
2.独立开发、独立部署 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
3.增量升级在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
4.独立运行时 每个子应用之间状态隔离，运行时状态不共享

微前端需要考虑哪些技术点？

1.使用HTML入口还是使用js入口
    推荐使用HTML入口，天然的样式隔离，CSS和js可以并行加载，dom
    js入口需要all-in-js，无法进行并行加载，而且需要主应用预留一个挂载dom，且ID需要和子应用预设的一致
2.样式隔离
    子应用卸载时，同时卸载对应的css文件（所以HTML作为入口具有天然的样式隔离）,这种只针对一个路由的单应用
    CSSmodule处理  人为规定不可避免会出现问题，对于依赖模块的全局样式可能无法解决
    shadow DOM
    。。。
3.js全局变量隔离
    通常的方案，变量约定（不靠谱，不稳定）
    蚂蚁的处理方案，沙箱模式，在子应用挂载前对window对象做一个快照，当应用卸载时对window对象进行回滚

和iframe的对比：

iframe优势在于浏览器提供的资源硬隔离，不论样式和js全局变量等

缺点：

1. url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2. UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
3. 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
4. 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

 

拓展概念：去中心化配置

比如说一个router.js.没个大型的项目都会有路由的配置，当一个工程师说我不需要展示某个页面的时候，
需要考虑这个模块的修改是否会影响到其他的其他的团队或者模块，或者说这个文件的修改权限在其他的团队上，这个时候就会造成一些问题
比如说webpack.js
当多个团队进行开发时，你无法预知你设置的webpack会被修改成什么样子
package.json是同理
每个团队开发所需要的依赖库可能是不一致的，这就会导致相同的功能（比如说datePicker）可能会出现多个依赖库这样的冗余，而且很难进行修正

以上都是一些概念上的梳理，接下来会着手进行实际的落地，期间遇到的问题和解决方案也会尽快更新

参考文章：

https://zhuanlan.zhihu.com/p/78362028
https://www.yuque.com/kuitos/gky7yw/rhduwc