vue 3.5 propsDestructure 破坏了现有的响应式原则

[guaijie]

Vue version

3.5.3

Link to minimal reproduction

https://blog.vuejs.org/posts/vue-3-5#reactive-props-destructure

Steps to reproduce

vue3 围绕着两种响应式数据结构，分别是 ref 和 reactive，但 propsDestructure 出现却破坏了这一点，我将从一下几个方面阐述我的观点以及提出个人的建议：

1. 破坏了 vue3 现有的响应式原则

const { count = 0, ...rest } = defineProps<{
  count?: number
  message?: string
  disabled?: boolean
}>()

上述代码中，count 看上去只是一个类型为数字的变量(它并不是 ref 和 reactive 中的一种)，但它因为最终会被编译成 props.count 而具备响应式。单从代码的角度看上去似乎是增加了一种响应式数据结构，但又无法直接分辨这一数据结构与普通数据结构的差别。

2. 依赖关系变复杂，失去可读性和增加了维护成本

// 虽然在 vue2.x 中的我们需求提前确定依赖关系，但也增加了代码的可读性和减少了维护成本
// 过去
const computedRef = computed(() => {
  // 清晰明了的依赖关系
  const { count, message, disabled } = props
  // ...
})

// 现在
const computedRef = computed(() => {
   //  count, message, disabled 与其他普通的变量混杂在一起，依赖关系变得复杂
  // ...
})

// 这一问题同样也出现在 watchEffect 中， 这一行为意味着我们更难直接从繁杂的代码中一一理清依赖关系
// ref 能一定程度解决这一点是因为我们可以通过查看它的类型知道它是否是一个响应式数据

vue 的维护者不应该一味的追求代码的书写方便而丢失可读性，书写的人只为了一时爽，但后期维护者以及维护的成本该怎么办

3. 梦回 $() 宏

在 vue3.4 中废弃了 $() 来创建响应式变量，而如今它似乎又出现在 defineProps() 中

$() 的出现确实给开发者带来便利，但它被废弃的其中一个原因就是解构出来的变量与普通变量无法进行很好的区分，导致在使用时很难去理清整个依赖链。

What is expected?

为解决以上问题，有几点建议：

1. 对于开发者而言，在 vue3 中解构响应式数据而丢失响应是一个根本性问题，它不应该只针对于 props。而是针对所有响应式数据。

const { count = 0, ...rest } = defineProps()
const {} = useAttrs()

2. 丢失响应是关键，应该利用现有的两种响应式数据结构 ref 和 reactive 来实现

const { count = 0, ...rest } = defineProps<{
  count?: number
  message?: string
  disabled?: boolean
}>()

上述代码中，count 应该是一个 ref 类型，rest 应该是一个 reactive 对象

toRefs 最大的问题在剩余属性不是一个 reactive 对象而是一个由 ref 属性组合而成的普通对象, 因为缺乏可以修改 destructure trap ，所以无法从根本上解决此问题。因此，toRefs 很少被使用（事实上可以移除该 api，如果需要，开发者可以自己实现，vue3 提供的 api 实在太多了）

// rest 不是一个 reactive object 而是一个 {[key: string]: Ref<any>}
const { count, ...rest } = toRefs(props)

3. 实现一个类似 $() 的宏

const { id, class, style, ...rest} = $(useAttrs())

• 如果解构出来的属性被定义成一个基础类型的属性，那么该属性数据结构应该为 Ref
• 如果解构出来的属性被定义成一个引用类型的属性，那么该属性数据结构应该为 Reactive

4. 类型提示上区分 reactive object 和 普通 object

// 我们无法有效的区分 o1 和 o2 的数据类型，应为这两者在类型提示上都是普通对象，o2 应该被标注为一个 Reactive 类型的对象
const o1 = {}
const o2 = reactive({})

What is actually happening?

no response

System Info

No response

Any additional comments?

No response

[yyx990803]

响应式解构的 RFC 去年四月就已经存在，社区已经反馈讨论了一年多，the ship has sailed，这个功能已经成为稳定功能，现在才提想法已经没有任何意义了。类似 $ 的宏早就有过类似提案，并在讨论过程中被放弃了。

• 这个功能的稳定化是基于一年多用户实际使用的反馈做出的决定，你一个人的偏好不足够成为做出改动的理由，提出的时机也已经太晚。
• Volar IDE 中可以启用 props destructure inlay hints 来从视觉上明确区分结构的 props 和普通变量；
• 如果你不喜欢这个功能，可以全局配置禁用 reactive desutrcture。