背景
目前公司中后台项目是Monorepo的Vue2项目，包含X、Y、Z三条业务线，而某高P来了个需求，我们要上市啦，我们要技术团队要对齐大厂，所以React登基也该提上日程了，于是乎人来，给我前端后端配成1:1，下锅！！
怎么办
当然是，安心微前端改造吧run，
需求分析
先确立本次改造的需求点及期望收益吧
拆分解耦
- 按业务线拆分成不同的仓库进行维护，不同业务线的开发者更加独立，不同业务线之间互不影响
- 物理层面拆分，加速寻址，新增功能修改Bug更加迅速
- 逻辑层面拆分，杜绝引用混乱，不会出现A业务线引用B业务线组件的情况
加速体验
- 开发环境急速启动，提高开发体验
- 业务线按需打包，急速部署上线
侵入性低
- 微前端改造方案改动原有代码的侵入性降到最小，无需大规模改造，减少甚至消除回归测试的成本
学习成本低
- 开发人员无需感知拆分的存在，保持单页应用的开发体验，不需要学习额外的规则
统一技术栈
- 为了统一共建与技术沉淀，团队内工程统一到React技术栈，不再使用不同的技术栈进行开发
方案选择
目前我们是需要在保证远Vue项目正常的情况下，在后续迭代中新增或重构某些功能的时候使用单独的子应用进行开发，调研了以下几种方案：
NPM式
- 子应用以NPM包的形式发布
- 打包构建发布不是由基座管理
- 基座和子应用需要建立通信机制
- 无单页应用体验
- 路由地址管理困难
iframe式
- 子应用可以使用不同技术栈
- 子应用之间完全独立，无任何依赖
- 基座和子应用需要建立通信机制
- 无单页应用体验
- 路由地址管理困难
- (wujie)给出了解决方案，
e厂🐮🍺
通用中心路由基座式
- 子应用可以使用不同技术栈
- 子应用之间完全独立，无任何依赖
- 统一由基座进行管理，按照DOM节点的注册、挂载、卸载来完成
特定中心路由基座式
- 子应用之间使用相同技术栈
- 基座和子应用可以单独开发单独部署
- 子应用有能力复用基座的公共基建
最后选择了什么呢？是wujie吗，不是qiankun，为什么？因为任性，即使它：
- 基于路由匹配，无法同时激活多个子应用，也不支持子应用保活
- 改造成本较大，从webpack、代码、路由等都要做一系列的适配
- css沙箱无法绝对的隔离，js沙箱在某些场景下执行性能下降严重
- 无法支持vite等ESM脚本执行
但就是任性，甚至每个功能块css不做cssmodules，我们直接每个css加一长串prefixclassname
实践
目前的方案是，基于vue2的项目为基座，主要负责登录/通知/子应用注册，暂时不提供基座与子应用的通信，降低耦合，保留原vue2的Monorepo项目，即包含到店、到家、团购业务线的项目，然后在重构/新增功能的迭代过程中，在React子应用中实现，部分修改功能的情况下，就在vue2项目中进行开发
还做了什么
组件库的按需引用
由于设计偏向于直接基于Antd组件库进行设计，但是vue项目用的组件为iview，过时且老旧，功能欠缺，所以按需引用AntdV进行开发迭代，也方便后续全面转向React技术栈
表单配置化改造
背景
由于中后台项目仅服务于公司内部销售使用，管理，所以对于自定义化需求很低，基本上可以看作是通用后台管理系统，并且各业务线功能类似，均为列表、详情、新建，所以可以进行表单配置化改造，以达到降本增效目的
怎么做
目前的方案是只对详情页进行表单配置化改造，因为样式单一，场景单一，只做展示，如果交与开发人员开发，基本上会耗时4h，并且无法兼顾产品的随时变动
方案
基于Lowcode Engine进行开发，设计器直接复用Lowcode Engine的，只是对保存，JSON Schema做有限的修改，然后团队共同维护一个强业务组件库，如：私海客户搜索组件、组织架构选择组件等
整个流程改造成如下图示：
由于产品完成PRD基本上领先开发三个月，所以可以让手上暂无开发任务的前端去维护该次迭代需要的一些公共组件，抽离成组件库，由于业务单一可完全成为强业务组件，然后整个迭代的详情页均由PM和后端实现，前端只负责渲染器的实现。
怎样的流程
- 首先，后端提供一个JSON Shema的接收接口，这个接口对应这个详情页
- PM在设计器上新建工程项目，填入url，然后进行拖拽，填入对应的组件的key，即对应的详情字段，然后保存
- 设计器会将JSON Shema一份传给服务端，一份保存在远程OSS存储上面
- 后端拿到JSON Shema会连同detail的JSON字段一同传给前端
- 前端拿到数据直接渲染，不需要做其他的
结果
目前的结果是原先敏捷开发前端需要3个人，现在2人即可，节省了人力，剩余的人可以抽调去做H5相关或跨端相关
期望
能够实现整个中后台系统的配置化，目前需要两个节点事件：
- 项目完全迁移到React
- 组件库项目引用率100%
