The attr fall-through overrides the value of prop

[edison1105]

Vue version

3.3.4

Link to minimal reproduction

https://play.vuejs.org/#__DEV__eNqNUk1PwkAQ/SuTvQCJoUHUAykkajjoQYkaT3tpygDF7e5md4skTf+7s1tKQZDIgXTeezvz5qNk91r3NwWyEYttajLtwKIr9ITLLNfKOCjB4AIqWBiVQ4eknT31qHK9w/uRD3wmorlMlbQOcruEsX/e7Qyuh51egy/RfSaCqO4mET0YT6DkEuhnqLSRQCiXFZdxVFsiMxQ4zLVIHFIUh8ojyj/mrM7WpaDHGUSejg607Io5S3UX2bK/tkpSp6EaZyklyQSaV+0y8sXZqPHBWSKE+n4OmDMFXjV4usL06wy+tluPcTYzaNFskLM95xJDHmt6+v6CW/rek7maF4LUF8g3tEoU3mMteyjknGwf6ILbp7CUTC4/7HTrUNqmKW/UK6ug54yW5Of3V+ut3WF/GN7RMmiKzYJPT8VcOpaW9AkGR/cyqA+GJCcHc3N7RwdDTHsEFASgXa6P6qy7W6D/+gbCwyPhroNQ8ncLIBLpnzuaRBDPcZFJnBmlbVx6wI+Gko/AOkMj9lA16f7HIEC8GkzKMjRXVXFE0Tl71Q8cWjJw

Steps to reproduce

open the link

What is expected?

show 456

What is actually happening?

show 123

System Info

No response

Any additional comments?

No response

[posva]

I would say this is expected: the same happens with an attribute and one can disable it with inheritAttrs: false. It's also a breaking change but I really don't think it's worth since it's less flexible than the current behavior

[LinusBorg]

you can also use the .attr modifier to prevent this /enforce the passed-through attribute be be applied as an HTML attribute, thereby not overriding the prop:

https://play.vuejs.org/#__DEV__eNqNUk1vwjAM/StWLoA0tWJsO6CCtE0ctsOGtmmnXKpioCxNoiRlSFX/+5yU8jEYGgdUP7/Yz/ar2L3W0bpENmSJzUyuHVh0pR5zmRdaGQcVGJxDDXOjCugQtbNLPapCb/Eo9oGvRGkuMyWtg8IuYOSfdzv960Gn1+ILdJ+poFR3nYoejMZQcQn0M9TaSCCUy5rLJG4kkRgKHBZapA4pSkLnIdWPUufMiLOmZJeQHmcQe0588IBdMWep+TxfRCurJI0bWnKWUaVcoHnVLidxnA1bMZylQqjv54A5U+JVi2dLzL7O4Cu78RhnU4MWzRo52+Vcakhjk568v+CGvnfJQs1KQewLyTe0SpReY0N7KOWMZB/wgtqncJlcLj7sZONQ2nYoL9Qz68DnjC7ll/jX6Hu5g2gQ3tFFaIvtlU/9Yi45Zp/0BfpHpuk3riHKiWtubu/INZTZO4GCAOyP66OmqjcEeYH+Gw+Eh0fE7QSh5e8RQKTSP3e0iUCe4TyXODVK26TygF8NFR+CdYZW7KF63P2PQIBk2R9XVRiurpOYonPy6h/DwjRZ

[edison1105]

Please NOTE:

• This behavior is inconsistent to vue2 and we didn't documented in the docs.
• This kind of overriding prop behavior is unstable. If the user modifies the template of Comp.vue in the future (e.g. adding a <div> in the root), it may cause the attr to no longer fall through to Comp1.vue, and the rendering result may be different. This is something that is difficult to foresee in advance. It is also not easy to track down the root cause of problems.

[posva]

It still look more convenient to me for the points mentioned above. The current behavior feels like an improvement as it's more predictable that having different behaviors for attrs and props

[LinusBorg]

In principle, I agree with @edison1105 - strictly speaking, it's an undocumented behaviour and its unstable nature can, in edge cases, lead to subtle bugs in use's apps.

Practically speaking though, this behavior has been around for so long that "fixing" it now will inevitably break some existing userland code where that behavior is used on purpose by devs who understood the feature to work this way implicitly.

So what are our options:

1. "Fix" it and risk breaking user's code.
2. Add a runtime warning of some kind
3. Document the behavior, while giving recommendations like:

When using fallthrough attributes, we recommend explicitly declaring them as attributes using .attr or DOM properties using .prop in order to avoid a nested ancestor root component accidentally consuming them as a component prop".

We could combine this with a note about how we intend to change this behaviour in the next major - provided that we agree on wanting to do that and whenever we would do Vue 4, for which there are no current plans)

As a general note: Fallthrough attributes are a convenience feature that are a bit unstable by their nature. In a variation of edison's example, consider a component that has <input> as the root element, and then a <label> is added as the new root node to wrap the input properly. Now a id fallthrough attribute will falsely be added to the <label> instead of the input.

[so1ve]

What about a feature flag?

[jods4]

Duplicate of #6325 ?

[LinusBorg]

What about a feature flag?

something like inheritAttrs: 'avoid-props-override' ? (not attached to the specific name).

It seems to me it can't be a global flag (at least not exclusively) as it would easily lead to weird bugs in 3rd party components relying on it.

So it would have to be a guard implemented in each receiving component. Could work but feels cumbersome as you would likely want to add it to practically all of your components once you use it, to be consistent.

[LinusBorg]

Duplicate of #6325 ?

Seems to be, yes. We might want to close that old one as this one here already has a good chunk of discussion now.