前言

在公司层面，期望统一一个前端技术栈，那就是基于 React 的前端技术栈。

对应电商 B 端前端，最核心也是最主要的站点就是 Amaze 了。

而 Amaze 从现在的 Angular 迁移到 React 的事情之前也都经过了很多的调研。

但最后都因为遇到跟 Angular 的各种兼容问题而放弃。

从我个人的角度看，失败的一个重要原因就是想在 Amaze 当前项目基础之上去做改造和适配。

Amaze 东西太多太杂，牵一发而动全身，直接改造成本是非常大的。

最好的做法必然是另辟蹊径，搞一个完全独立项目从 0 开始做起。

也就是下面这个架构图。

架构图

方案详细设计

整体架构图是比较清晰的。就是搭建一个全新的 React 项目，然后新做的页面以及需要重构的页面都放到新项目里去开发。

但是在迁移过程中难免会有很多的问题，涉及到的细节点也会非常的多。

比如某个页面非常大，涉及到的东西非常多，或者说有很多的外部依赖。

这些问题肯定是无法避免的，我们需要做的就是具体问题具体分析。

整体的实施流程

但不管怎么说，整体的方案实施流程应该是：

1. 先梳理所有现在用到的业务组件。
2. 调研 Ant-D及其他外部成熟组件库，然后逐步使用 React 重写这部分组件。
3. 同时搭建我们的开发项目，做好本地的开发、测试和线上的构建及部署。
4. 完善必须的业务和页面级组件及必要的功能开发。
5. 最后，逐步迁移各个子页面。

项目搭建

纯静态 vs node 服务

纯静态的问题也是很多，比如开发环境请求 https 带不上 Cookie 的问题。

采用 node 服务的话，优势就非常的大，一个是能极大的增强个人的知识面和技术广度，二是可以做更多的以前想做而比较难做到的事情，比如直接鉴权。

项目组建方式

现在的 Amaze 项目已经在做的一个事情是逐步拆分成各个子站。最终达到的是完成独立开发和部署。

主要的原因还是在于发布上线太慢了。

但，现在有了 vite，发布的时候可以直接使用 es6，因为我们不需要兼容低版本浏览器。

所以，初步想法还是放到一块。

导航

目标是做成配置化的形式，前期如果工期问题的话，可以直接写死。

过渡期间需要在两个项目里同时修改。

跳转

过渡期间，优先使用直接跳转的方式，后续如果确实不可预知的问题的话，可以使用 iframe 的方式嵌入。

但不管怎样直接跳转的方式都无法避免体验差的问题，这个在过渡期间先不考虑。

业务组件

目前最大头就是业务组件，我们前期需要逐个的梳理。如果可以的话，需要排一个优先级。

其他团队现状

组件库现状

目前跟增长团队聊过，目前他们那边已经完成了大概 70% 的迁移任务，但 React 组件沉淀不多，都是一些简单输入组件，比如：图片上传、数字范围的输入。 更多的沉淀是在技术选型上。目前是基于 AntD、Formily v2、ProTable 来开发。并且自己攒了一个带鉴权的路由配置。

跟基础架构团队聊过，目前他们准备在 Q4 开始启动 React 组件库的建设，具体时间还不确定。

所以，组件库这块的整体构建还是需要我们自己去做的。