Destructured prop variables aren't returned from setup()

[magicandskill]

Vue version

3.4.29

Link to minimal reproduction

https://github.com/magicandskill/vuejs-props-reassignment-reactivity/tree/main

Steps to reproduce

npm install,
npm run dev,
press the add count button,

What is expected?

Props destructuring like this:

const { text, count } = defineProps(['text','count'])

doesn't affect the reactivity of the props within the template because these variables aren't returned from setup().

But reassignment like this:

const props = defineProps(['text','count'])

const text = props.text
const count = props.count

will make the props not reactive in the template because they get returned and mask the props in the template.

These two versions are creating the same variables, so the results should be consistent.

What is actually happening?

Inconsistent behaviors in regard to returned variables from setup().

System Info

No response

Any additional comments?

No response

[wangyewei]

https://vuejs.org/guide/extras/reactivity-transform.html#reactive-props-destructure

[linzhe141]

const props = defineProps(['text','count'])
const text = props.text
const count = props.count

When the App component changes the text and count, the render function of the Hellowold component will be re-executed, but the setup function of Helloworld will not be re-executed, so the text and count returned by setup will not change.
So I think this should be correct.

[magicandskill]

const props = defineProps(['text','count'])
const text = props.text
const count = props.count

When the App component changes the text and count, the render function of the Hellowold component will be re-executed, but the setup function of Helloworld will not be re-executed, so the text and count returned by setup will not change. So I think this should be correct.

But with const { text, count } = defineProps(['text','count']) the props will still be reactive within the template. I'm saying these two versions are creating the same variables, their results should be consistent.

It looks like script setup automatically returns all variables except the ones created through props destructuring

[linzhe141]

const props = defineProps(['text','count'])
const text = props.text
const count = props.count

When the App component changes the text and count, the render function of the Hellowold component will be re-executed, but the setup function of Helloworld will not be re-executed, so the text and count returned by setup will not change. So I think this should be correct.

But with const { text, count } = defineProps(['text','count']) the props will still be reactive within the template. I'm saying these two versions are creating the same variables, their results should be consistent.

It looks like script setup automatically returns all variables except the ones created through props destructuring

You are right, the compilation results of these two are different

[yangliguo7]

@magicandskill

When props are changed, the reason for the execution of the render function is because during template parsing, reading props will store the render function as a dep.
As @linzhe141 said
The template parsing here does not store changes to props as dependencies

[magicandskill]

@magicandskill

When props are changed, the reason for the execution of the render function is because during template parsing, reading props will store the render function as a dep.

As @linzhe141 said

The template parsing here does not store changes to props as dependencies

This issue isn't about reactivity per se, it's about consistency in regard to what variables get returned from the setup().

Destructured prop variables don't get returned from setup(). Look at the other screenshot from @linzhe141.

[yyx990803]

There is indeed an inconsistency. In 3.4 Reactive Props Destructure (RPD) is disabled by default. The destructured props happens to be reactive in templates because they are of the same name. It breaks if they are destructured with alias.

This is fixed in the 3.5 minor branch in 0fd6193.

Not releasing this in 3.4 line because this might break code that previously relied on the previous behavior. They would continue to work in 3.5 with RPD enabled by default. So the only case affected will be those who choose to explicitly disable RPD post 3.5, and should result in minimal impact on end users.