About props

[APGPerson]

When I was learning how to use a ref object as a prop,I couldn't understand why

const { foo } = defineProps(["foo"])
watch(foo,()=>{}) // Not work
watchEffect(()=>{
foo
...
}) //Work well

I know it will compile to

const prop = defineProps(["foo"])
watch(prop.foo,()=>{}) // Not work
watchEffect(()=>{
prop.foo
...
}) //Work well

But I can't understand why prop.foo can't detected by watch()
AI told me it will auto unpack ref data,so prop.foo is just normal object
But I have learnt watchEffect() detect releative data by call it's getter or setter,if prop.foo is just normal object,it doesn't have getter or setter,so what causes this

Because it's difficult to read all source code about this part for me,so I came to there for help
Thanks

[ismaildasci]

Hey, I had the same confusion before so let me explain what I learned.

When you destructure props like this:

const { foo } = defineProps(["foo"])

you basically extract the value at that moment. Its not reactive anymore, just a plain value. Thats why watch() cant detect changes.

But watchEffect works different - it tracks whatever you access inside it while running. So when you use foo inside watchEffect, Vue still catches it.

What you can do:

Use getter function in watch:

const { foo } = defineProps(["foo"])
watch(() => foo, (newVal) => {
  console.log(newVal)
})

Or dont destructure and use props directly:

const props = defineProps(["foo"])
watch(() => props.foo, (newVal) => {
  console.log(newVal) 
})

Or use toRefs if you really want destructuring:

const props = defineProps(["foo"])
const { foo } = toRefs(props)
watch(foo, () => { ... }) // works now

Basically destructuring = copying value = losing reactivity. Hope this clears it up!

[APGPerson]

But according to the document

In version 3.4 and below, foo is an actual constant and will never change. In version 3.5 and above, Vue's compiler automatically prepends props. when code in the same <script setup> block accesses variables destructured from defineProps. Therefore the code above becomes equivalent to the following:

const props = defineProps(['foo'])

watchEffect(() => {
  // `foo` transformed to `props.foo` by the compiler
  console.log(props.foo)
})

props.foo doesn't destructuring props

If I am wrong, please point it out.
Thanks for your answer

[skirtles-code]

Props destructuring is a distraction here. You're essentially correct, that it compiles watch(foo, ... to watch(props.foo, ..., so the real question is why doesn't watch(props.foo, ... do what you want?

To be a bit more explicit, consider this code:

const props = defineProps(['foo'])

watch(props.foo, () => {
  console.log('changed')
})

As you noted, this won't work. Here's a Playground showing that:

• Playground

As well as not triggering the watcher, you may also notice that Vue logs a warning.

When we write watch(props.foo, () => {...}), we aren't passing the expression props.foo to watch, we're passing its current value. In my Playground that value is 1. So we're essentially calling watch(1, () => {...}). That's why we get the warning, because watch receives a source value of 1 and doesn't know how to watch 1.

Contrast that with what happens when you pass a ref. Say we have something like this:

const r = ref(1)

watch(r, () => {...})

In this case, the 'expression' for the first argument is just r. Again, watch won't know about that expression, it will just receive the current value of that expression (this is a normal JavaScript function call, no special Vue magic involved). The current value of r is a ref object, and watch knows how to watch that: it needs to watch the value property of that object. All is well, as that's what we wanted it to do.

Now consider this case, similar to the earlier example but with a function wrapper around props.foo:

const props = defineProps(['foo'])

watch(() => props.foo, () => {
  console.log('changed')
})

This will work correctly:

• Playground

The key thing here is that we're passing the wrapper function to watch, not the current value of props.foo. When watch receives a function it knows how to watch that: it starts tracking and calls the function, very similar to what it does for watchEffect. This allows it to track the property access and record it as a dependency of the watcher.

In general, Vue's dependency tracking relies on where properties are read. You can think of this as a dot operator, .. So when we write props.foo, that is reading a property. It needs to be read somewhere that Vue can track it (a more technical description of this is 'it needs to be read inside a reactive effect'). In practice, that means it needs to be inside a function. Being inside a function allows Vue to start tracking and then call the function. Dependencies are then recorded while the function is running. If those dependencies subsequently change then Vue can re-run the function and re-gather those dependencies based on their new values.

Going back to the earlier example with a ref called r, you can think of watch(r, ...) as being a shorthand for watch(() => r.value, ...). When watch receives a ref for its source it just wraps it with a function like this. You can see this part in the Vue source code here:

core/packages/reactivity/src/watch.ts

Lines 153 to 154 in aa9af1d

	if (isRef(source)) {
	getter = () => source.value

While this can sometimes be difficult to follow at first, one 'simple rule' that many of us use to spot mistakes quickly is 'dots should be inside functions'. This is only a guide, it sometimes won't apply, but it comes from the idea that reading properties needs to happen inside reactive effects. So consider these examples:

watch(a, ...)         // 1
watch(() => a, ...)   // 2
watch(a.b, ...)       // 3
watch(() => a.b, ...) // 4 

1. The first example is just using a. No dot, no function... all is well.
2. The second example has no dot, so it probably shouldn't be using the extra function. No property access occurs inside that function, so nothing will be tracked.
3. The third example does have a dot in a.b. This is probably wrong because it isn't inside a function.
4. The last example has both a dot and a function, so that's fine.

Props destructuring is an awkward edge case in this regard, but so long as you know that foo really means props.foo it essentially works the same way, dots inside functions.

Likewise, even if you aren't using props destructuring, you get something similar when you write something like {{ foo }} in your template. The 'function' in this case is the component's render function, which is generated from the compiled template. The dot is not immediately obvious, but templates have special handling for props and {{ foo }} is reading from props.foo, which gives us our dot.