背景
做了一个叫rximg的开源项目，是想将图像处理的流程做成拖拖乐的形式。项目开始时候采用的是Vue.js 2.0，是因为自己多年前用过Vue2，较熟悉这一套技术栈。但开发到后期，发现依赖的一些开源框架，纷纷开始支持vue3和ts，Vue2的版本不更新了。因此，半路对整体框架进行大改，改完之后感受良好。
这是项目的演示。
rximg 读取图片并显示
这是项目地址：github.com/rximg/rximg
依赖库变化
| 旧版本 | 新版本 | 变动类型 |
|---|---|---|
| Vue.js 2 | Vue.js 3 | 升级 |
| vue-cli | vite | 更换 |
| Javascript | TypeScript | 升级 |
| Ant Design Vue 1.x | Ant Design Vue 3 | |
| vuedraggable-next | 升级 | |
| vuex | 删除 | |
| antv-x6-vue | 新增 | |
| vueuse | 新增 | |
| vue-socket.io | socket.io-client | 更换 |
选项式VS组合式
高内聚低耦合
这次更新最大的改变是用VUE3中的reactive和组合式API，重构了项目中的状态管理的这一部分。VUE2中，状态管理是由VUEX框架维护一个全局的状态树，然后通过一系列定义在getters、mutations中的接口将状态响应式的映射到View层。而这种映射过程，是以向VUE的选项式API里填充代码的形式实现的。可能这种方式是符合前端函数式的大趋势，但是对于用惯了面向对象的我来说，用的是十分难受。
我本人写的比较多的是后端和算法，用python用的多。通常来讲，面向对象有个好处就是可以把数据和逻辑搞得"高内聚，低耦合"。面向对象最基本的概念就是，一个对象不仅封装了自己的数据，还提供了操作自己数据的方法。而选项式的API拉远了那些本来应该很近的数据与逻辑，暴露了很多不需要暴露的逻辑，增加了思维负担。
丢掉了VUEX
因此，我在重构时候，我将旧的模块重新划分了一遍，然后发现，我这个项目其实也不需要一个VUEX了。我这里并没有将VueX换成Pinia，而是直接将VueX干掉了。因为，Vue2中一切是选项式的，我需要一个VueX这样的东西将数据响应式的嵌入项目。但有了组合式的API后，VueX唯一剩下作用就是提供一个全局的获取数据入口，这个入口在多个组件中共享。而这个功能可以用别的简单方式实现。
面向对象的方式管理了数据和逻辑
最常用的一个对象以这种方式管理，避免了这些数据和逻辑分散到各个Vue的选项式的模板中去。
export interface RXFunctionInterface {
uuid: string | ComputedRef<string>
args: Record<string, RXArg>
op: string
name: string
type: string
from: string
returnType?: string
extraInPorts?: Record<string, number>
toString(): string
tojson(): any
md5(): string
onSubmit():void
}
\
迁移中的注意事项
解包需要注意
ref变量在使用时候需要频繁的在.value中拆包和组包，而且有的地方会隐式的自动解包，细节非常多，需要十分的注意。
Ref类型声明
可以将类变量申明为Ref类型，这样就知道这个变量是响应式的修改的，但reactive变量没有这种类型声明，在修改时候就无法判断是被修改的变量是不是响应式的。不过，官方似乎也不建议给reactive变量做响应式的类型声明。
深层次的响应式转化
reactive是递归的将深层次变量都转化为响应式的，如果只对第一层做响应式转换，需要用shallowReactive。
别纠结了换Vite吧
在迁移之初，我还是沿用vue-cli构建工程，各种问题不断，解决问题的资料也不好查，后来直接换成vite，把项目重新配置了一遍就好了。所以对于Vue3和ts的项目而言，还是别纠结了直接用vite吧。
Volar
我是用vscode的，Vue的插件要由Vetur换成Volar。
对于旧版本的选项式代码如何处理
旧版本的选项式的代码很多可以直接用，或者稍微修改一下直接用。现在的项目中依然有选项式的.vue文件。Vue3对选项式的兼容，对于这次升级的平滑度还是起了很大的作用。
不过由于之前代码和VueX是强耦合，而现在去掉了VueX，代码逻辑始终要大改，就趁这个机会把绝大部分component换成组合式的了。
