【方案设计】状态管理从 vuex 迁移至 pinia

[j10ccc]

方案介绍

背景

vuex 注册、声明、消费状态的方式繁琐，并且没有类型提示，开发体验很差。

原逻辑中的 vuex 会将状态全部存到一颗状态树下，持久化后数据全存在 storage 的一个键值对下，对调试状态不友好。

新人上手项目要先熟悉 vuex，心智负担重。

价值

本次改动一方面为了跟上前端技术的步伐，另一方面能降低项目维护成本和新人上手难度。

目标

本次改动是纯前端的技术性改动，计划将 vuex 全部替换成 pinia，将状态管理逻辑提取成 hook。

影响的模块

主要影响三处

1. 对 vuex 状态的声明，代码在 src/store 下
2. 在接口函数处的消费，代码在 src/service 下
3. 在 vue 组件中的消费

方案设计

技术方案

现版本中，部分代码的业务逻辑（状态管理）和请求函数强耦合(具体见 updateDateStateWithSession 函数)，需要做拆分。要想剥离掉 vuex，必须先把状态的维护和请求函数的声明拆开，具体的拆分方案如下

• 之前对新业务做过一次过渡性迁移，声明了不少纯请求函数(使用 services/request.ts)，本次计划将所有请求逻辑替换成的纯请求函数，仅仅保留请求入参，响应的返回。原调用 updateDateStateWithSession 来实现状态更新的逻辑，拆分到 hook 中实现。
• 对于具体的业务逻辑，在 src/hooks 下创建具体的模块文件夹来实现。

计划以 src/services 下的模块为单位进行重构。下面是执行重构的方案

1. 上手一个模块时，先观察他影响到了哪些 src/store 下的模块。
   1. 模块中若有个逻辑调用了旧的请求逻辑，把请求函数改写成用 request 实现。
   2. 模块中若有具体的业务逻辑，安排在 hook 中实现。
2. 用 pinia 复现 store 的 getter/setter 逻辑到 hook，用 defineStore 写一个 useStore。
3. 整合service 下的业务逻辑、消费请求函数以及刚刚声明的 useStore 到 hook。
4. 评估 vue 组件中的业务逻辑抽离到 hook 的价值，并落实。

灰度方案

在体验版过渡两个 minor 版本后，作为 patch 版本上线。先在办公室灰度 2 周，后缓慢放量给用户。

[j10ccc]

按照 src/services/services 下的模块来分工

@j10ccc

• canteenService.ts
• libraryService.ts
• lostfoundService.ts
• systemService.ts
• authService.ts
• suitService.ts

@xixiIBN5100

• yxyService.ts
• userService.ts
• zfService.ts