$attrs is reactive in Vue3 composition API, but the docs say they aren't.

[TheDutchCoder]

Are the docs incorrect, or is this actually an internal bug?
When we apply $attrs.class for example, it changes when the parent's :class updates, which, according to the docs, shouldn't happen.

We don't want to use this if it's actually a bug.

[LinusBorg]

I assume you refer to this paragraph:

Note that although the attrs object here always reflects the latest fallthrough attributes, it isn't reactive (for performance reasons). You cannot use watchers to observe its changes. If you need reactivity, use a prop. Alternatively, you can use onUpdated() to perform side effects with the latest attrs on each update.

This is not in contradiction to what you are experiencing, though the wording could be improved I guess. The last sentence indirectly explains what you are experiencing:

Alternatively, you can use onUpdated() to perform side effects with the latest attrs on each update.

To put this in more explicit terms:

• When attributes are changed in the parent, the renderer triggers a re-render of the child.
• During that re-render, the non-reactive attrs object contains the new values
• which will be used in the child's render update, and you see the template update
• and you can get the new values in i.e. the onUpdated() lifecycle hook.

So both things are correct:

1. the attrs object is not a reactive proxy, so you can't watch() it or rely on it as a reactive dependency in computed() etc.
2. but when attributes are changed in the parent, their new values will propagate to the child through a forced re-render.

When we apply $attrs.class for example, it changes when the parent's :class updates, which, according to the docs, shouldn't happen.

Well, if a change from the parent would not reflect in the child, that would make attrs essentially useless, wouldn't you agree?

[c5n8]

I appreciate the explanation. That said, I’m still struggling a bit with the mental model. I fail to produce any functional difference in behavior between attrs and props other than isReactive.
For all intents and purposes, they walk and quack exactly the same. watch and computed working perfectly in practice, being told it "isn't reactive" feels like a riddle.
I’d love to see a clear table of comparison in the docs to help bridge this gap. If the difference is purely internal implementation, it would go a long way in clearing this up for everyone.

Playgrounds:
ref value passed as an attribute
reactive object property passed as an attribute
object inside ref passed as an attribute

[c5n8]

Sorry, this is not an answer, I should have sent it as a reply.

Archived

I appreciate the explanation. That said, I’m still struggling a bit with the mental model. I fail to produce any functional difference in behavior between `attrs` and `props` other than `isReactive`. For all intents and purposes, they walk and quack exactly the same. `watch` and `computed` working perfectly in practice, being told it "isn't reactive" feels like a riddle. I’d love to see a clear table of comparison in the docs to help bridge this gap. If the difference is purely internal implementation, it would go a long way in clearing this up for everyone.

Playgrounds:
ref value passed as an attribute
reactive object property passed as an attribute
object inside ref passed as an attribute

[TheDutchCoder]

I think the difference is that when attributes change, a whole re-render is triggered, instead of a partial one (which would happen when a prop changed).

The fact that it feels reactive is because the setup function is ran again.

But I'm also struggling with the onUpdated, which feels useless if the component rerenders anyway?

I guess this boils down to a theoretical vs. practical difference?

But I might be completely wrong of course 😅

[c5n8]

Archived

Setup function is NOT ran again, at least not in the playgrounds I shared.

[TheDutchCoder]

Hmmm, then I have no clue haha