# 微前端调研的思考
# 市面上比较火的微前端
乾坤
# 理念
不是很远的概念，是解决问题的思路
# 未来
webComponent ， 腾讯开发的 omi xtag
# 思考
我做这件事情为什么，以解决问题的思路，一步步探索，我们现阶段存在什么问题，这些问题的话 我们应该以什么样的方式解决这些技术热点
# 透过现象看本质
- Bit.dev (opens new window) 可以理解为组件市场，像阿里的飞冰 解决一些工程化的问题 工程化体系的建设，高频的前端开发解决方案，物料概念， 像 antdesign 饿了么，这些原子组件可能不是很满足我们当前业务，通过平台管理我们业务组件，通过事例 来公用，通过 npm 系统进行引用，通过平台可以将其管理起来， 我们去年梳理 目前有上百个系统，如果系统升级的话没有很好的管理 很难进行同步，收敛统一组件，有组件市场我们可以对市场升级，例如： 飞冰 (opens new window) ，可以有快速 ，有物料市场， 可以通用 ，自己约定组件库， Bit 的可以不用它，可以借鉴它的思想，可以让其收敛，避免重复工作 ，在当初我们随着人员增加很有必要做这样一件事情，统一技术栈 ，为团队扩张做更好的准备，当人扩张到一定时很难控制，工作量特别大， 船大难掉头，有比较大的收益，通过 c 端 b 端 m 端 进行归类， 团队快速发展，每个人要实现完整逻辑 有些重复，有点像 github，有代码事例，可以直接引用
- Webpack 的 Module Federation (opens new window) 插件构建微前端， web 一般用 webpack 项目搭建，另一个系统复用页面(一般拷贝代码，npm 包)， 而 webpack 5 是事注册， 配一个 plugin ，本质是快速复用另一个系统代码能力，实际上就是让我封装引用的更优雅
- single-spa (opens new window) 阿里乾坤也是基于它做的， 解决的是 iframe 的问题，把路由 iframe 变成 react 路由
- shoelace (opens new window) 和 antdesign 一样， 不依赖框架， 引入 sdk 和 css 就可以用， 基于 webcomponent 做的，现代化的浏览器
# 如何跨框架复用
最简单 发包， reactDome render ， props 变化 通过其他机制传参变化 为什么微前端会火 一个多框架兼容的组件库的成本： 人力 _ 时间 _ n （框架种类） 组件跨框架复用问题相对于组件库来说可能更加明显，所以为了更好的解决开发者开发体验， 才会出现微前端
# 本质
本质都是 html css js 似乎前端越发展，复用能力越弱了， jq 时代百度随便搜一下 就可以解决， 在这样的背景下出现了 微前端的方案， 把本地 copy 另外一份 我们最终希望的结局方案 不需要考虑语言是什么，框架是什么 ，亦或是原本的项目环境是什么， 本质是相同的
# 微服务本质什么，要怎么理解前端 DDD
DDD 领域驱动式的设计模式，把一个大问题 拆分 各种各样的小问题， 然后逐个解决 微前端核心 l 理念中是微服务，后端微服务怎么实现的，其实就是把能够独立的逻辑抽象为实体，来让它达到更灵活的“可拔插”复用性，不用考虑语言，不用考虑框架，甚至不用考虑环境(基于 docker)，和我们最初预期很相符，就如我们事例一样，一个复杂系统中的各项服务都可以拆成单一实体，封装成镜像之后，可以被带到任何需要它的地方以便复用 后端有一个服务，对接微信 ，对接网站， 本质是一个 docker ，有端口号，通过网关对接，通过封装好的镜像引用进来 微服务本质： 在编程世界里，最重要的就是抽象能力，微服务改造的本质就是个抽象过程
# 设计理念
single-spa 路由驱动式微前端框架,原理核心： 就是路由变化时，判断激活和销毁的应用，触发子应用对应的生命周期实现应用的切换。1. 需要预留占位 DOM 并能够被获取，让子应用的 mount 的生命周期有地方挂载，主从应用在逻辑上需要一致的约定。 2. 主应用层需要感知复杂的子应用注册并调用，不够丝滑，虽然这层在框架上给你做了，3. 子应用不感知父元素的状态变化，需要通过事件或者全局数据管理完成父子交互， 与现阶段声明式的前端开发习惯有些差异 4. 实现粒度停留在路由级，对抽象逻辑有所限制，还可以更加极致
# 总结：
- 劣势： 主从应用在设计上其实没有太大关联，主应用只是完成了子应用的生命周期调度
- 优势：对老逻辑能快速的承接，快速封装微应用