下面是Vue3官方中对于 reactive 局限性的描述： ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/499c18435488493487e67544515c9a76~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=743&h=272&s=29213&e=png&b=ffffff) 我相信所有的人看到这段文本都不会意识到它具体意味着什么，我如果不是踩过坑，我也不太能够体会这段话的含义。本着“自己掉坑了不想别人继续掉坑里”的想法，我写了这篇文章。 ## 掉坑下面是复现坑的简略版本代码 ```js // @/stores/test.ts import { reactive,ref } from "vue"; import { defineStore } from "pinia"; export const useStore = defineStore("test", () => { const dataList = reactive([{ name: "Tom", age: 18 }]); return { dataList }; }); ``` ```js // @/components/App.vue ``` 渲染后的UI: ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c64ad05fef9f43cd9df89b63204777fa~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=171&h=79&s=1617&e=png&b=fefefe) 此时，点击更新按钮，我们就可以发现并没有发生更新，显然这是违反直觉的，因为我已经调用store.$patch去进行更新了，为什么UI并没有同步更新呢？如果我们稍微修改一下代码： ```js // @/stores/test.ts /*省略其它无关代码*/ //const dataList = reactive([{ name: "Tom", age: 18 }]); const dataList = ref([{ name: "Tom", age: 18 }]); /*省略其它无关代码*/ ``` 此处我们将reactive 用 ref 进行替换，此时刷新网页后，我们就可以发现，单机更新按钮后，UI发生了改变。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a46cc91113d04a57bffd1dc128386422~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=128&h=72&s=1549&e=png&b=fefefe) ## 为什么会这样？导致这种区别的主要有两个方面的原因，第一个是因为 ref 与 reactive 之间的差异，第二个原因则是因为 pinia 的原因。 ### 先探究第一个原因众所周知，在Vue3中，ref 在 reactive 中会被自动解包，且解包后它们引用同一个源，例如下面的写法： ```js const msg = ref('Hello World!') const obj = reactive({msg}) console.log(obj.msg === msg.value)//true obj.msg="dog" //会导致 msg.value 的值也发生改变，并触发与 msg 有关的副作用 ``` 这很符合直觉，而且Vue3的文档也向我们说明了这件事情。但有时候，msg不单单只是"Hello World!"这种的基本数据类型，它也有可能会是一个引用数据类型。例如： ```js const msg = ref([{name:"Tom",age:18}]) const obj = reactive({msg}) console.log(obj.msg === msg.value)//true obj.msg=[{name:"Jack",age:20}]//同样的，会导致 msg.value 的值也发生改变，并触发与 msg 有关的副作用 ``` 这种写法可能就会导致一些问题，一部分用户对于引用数据类型，可能并不喜欢用 ref，而喜欢用 reactive。此时写法就变成了： ```js const msg = reactive([{name:"Tom",age:18}])//对于引用数据类型用 reactive const obj = reactive({msg}) obj.msg=[{name:"Jack",age:20}]//此时如果这样更新，msg将不会发生改变，这导致的结果是“响应式连接丢失” ``` 此处回到了文章一开头的Vue3文档所说的关于reactive的局限性的说明。也即，reactive 与 ref 间差异的地方是：一个 reactive 包裹的数据如果传递给另一个 reactive 数据的某个属性时，修改该 reactive 的属性的值为其它值时，其与一开始引用的 reactive 的响应性会断开，此种写法无法影响到一开始的 reactive，而如果使用的是 ref，则响应式连接依然存在，能够影响到ref。这意味着一种可能，就是如果两个 reactive 的某个属性如果引用的是同一个ref，则修改某个 reactive，会导致另一个 reactive 也发生改变。（reactive 与 reactive 之间，通过引用同一个 ref 连接到了一起） ```js const msg = ref([{name:"Tom",age:18}]) //注意 obj 和 obj2 ，引用了同一个 ref. const obj = reactive({msg}) const obj2 = reactive({a:msg}) obj.msg=[{name:"Jack",age:20}] //在这两个 reactive 某个属性引用同一个ref的情况下， //更新obj.msg会导致obj2.a也发生更新，并触发其相关副作用 console.log(obj2.a)//[{name:"Jack",age:20}] ``` 如果不是 ref ，而是 reactive ，则无法实现这种连接。 ```js const msg = reactive([{name:"Tom",age:18}]) const obj = reactive({msg}) const obj2 = reactive({a:msg}) obj.msg=[{name:"Jack",age:20}]//连接断开了，此处修改不会影响到其它reactive console.log(obj2.a)//[{name:"Tom",age:18}] ``` 综上所述，ref 显然比之于 reactive 要强大，因为它可以建立一种响应式连接，这种连接甚至能够使得重新赋值这个操纵会同步到其它引用同一个ref的响应式对象中。这也是为什么 Vue3 推荐使用 ref 的原因（哪怕是对于引用数据类型）。回到问题的一开始，在了解到 ref 与 reactive 的这种差异后，我们好像已经可以理解为什么使用 ref 替换 reactive 能够使得点击更新按钮后UI更新了。同时我们也能够察觉到 pinia 的实现恐怕有些问题。 ### 第二个原因，pinia 的问题 ref 替换 reactive 之后，更新的问题得到了解决。而我们已经了解到 ref 比之于 reactive 最大的优势在于其能够在多个 reactive 之间建立响应式连接。那么我们这里可以大胆的推断，使用 useStore() 后返回的 store 与 pinia 内部保存状态的某个对象其实是两个 reactive，只有这样才会导致使用 reactive 与 ref 之间效果的不同。（看过 pinia 源码的我~~大胆推断~~说出答案）实际上，store 与 pinia 内部保存状态的某个对象确实是两个不同的 reactive，因此在使用 ref 的时候，这两个 reactive 能够依托 ref 的特性而建立连接，而当使用 reactive 的时候，这种连接就容易断开。下面是`console.log(pinia)`的打印输出， ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a253f53668a44d7c9611a717e57594fe~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=564&h=324&s=33375&e=png&b=fffefe) > 约定： > - pinia 指的是 createPinia() 返回的结果 > - store 指的是 useStore() 返回的结果 pinia 的状态保存的位置有下面这些： - pinia.state.value[id]：获取到某id对应的 store 的 state - pinia_s.get(id)：获取到某id对应的 store - store.$state:一个getter/setter，其从相应的 pinia.state.value[id]中获取值主要有两个保存状态的地方，一个是 store，另一个则是 pinia.state.value[id] (后面用piniaState 指代)。回到掉坑的例子中：在初始化的时候，store.dataList 与 piniaState.dataList 指向的是同一个目标，也即用户在defineStore()中返回的 dataList 所对应的值。但当调用 store.$patch() 后，其内部更新的实际上是 piniaState.dataList，此时如果一开始的 dataList 我们是通过 reactive 创建的话，那么 piniaState.dataList = newDataList 这一操作就会导致 store.dataList 与 piniaState.dataList 间的连接断开，store.dataList 指向的值依然是旧值，而piniaState.dataList 指向的值则是新值。一般情况下，我们传递给组件的 props 都是从 store 上读取的，这就导致了一个问题（也即我踩的坑），当我们使用 store.$patch 去进行更新的时候，会发现更新失败了，UI没有发生任何改变。这显然是有问题的，我用 pinia 去进行状态管理，我竟然还需要在创建 state 的时候注意使用的是 ref 还是 reactive，这显然是不合理的。而这种不合理的原因在于 pinia 在进行状态管理的时候，使用了两个 reactive。一个是给用户使用的 store，另一个则是内部使用的 piniaState，且 pinia 默认了用户创建状态使用的是 ref，而 ref 可以将两个 reactive 连接起来。 ## 解决方案 - pinia 修复该问题，pinia 将通过 store 访问的 state 指向 piniaState，统一用一个对象进行 state 管理。 - 将从store读取数据的(store.dataList)写法改为从 store.$state 读取。 - 用 ref 代替 reactive 去创建 state。 - 不使用 defineStore(id,setupFunction) 的语法，而使用 defineStore(id,options) 的语法。（options语法内部使用 ref 包裹 state） - 写个 pinia 插件，同步一下 store 与 piniaState： ```js pinia.use(function ({ store, pinia }) { Object.entries(toRefs(store.$state)).forEach(([key, ref]) => { store[key] = ref; }); }); ``` ## 总结 1. ref 与 reactive 的一个区别是，ref 能够在 reactive 间建立连接。 2. pinia 的源码实现存在问题（v2.1.6），setupFuncion 语法中用 ref 创建state 与 reactive 创建 state 存在差异，其语义有差别。