Optional props declaration

[yyx990803]

Note: this RFC has been revoked and superseded by #154

Rendered

[sqal]

In addition, in this case this.$attrs and this.$props will be pointing to the same object.

How in this case would be handled the matter of different props casing? Will props exposed in $props still be in camel-case and in $attrs as defined on the component?

<comp prop-a="a" propB="b" />

$props['prop-a'] // or would it be propA?
$props.propB

[posva]

it would make sense to always receive a camel-cased in js no matter what version is used on the template

[houd1ni]

@posva you've written camel-cased in kebab. Read it twice before getting it :)

[gregaton]

When a component has no props declarations, all attributes passed by the parent are exposed in this.$props.

What would happen if there are props declared?

I really like the explicit props declaration. It's like a contract between a child and its parent component. Would be even nicer if we could declare events but I digress.

Anyway, I would be quite upset if people in my team would stop declaring props.
Maybe it could be considered to only allow this feature for functional components?

[houd1ni]

@gregaton Functional components aren't those just pure templates as we have still known. Look at #27 (comment)

So, I suppose, it's better to think how to optionally prevent teammates from not declaring props in particular teams and cases. I'm into it, by the way.

[gregaton]

@gregaton Functional components aren't those just pure templates as we have still known. Look at #27 (comment)

It sounds like it but I know too little about the implementation details to say if it's feasible or not.

[pikax]

Sounds a bit confusing $attrs and $props sharing the same values.

If we declare props does it exclude the declared from $attrs?

What will be the recommended way to access passed values to the component? Seems the newcomers would probably abuse $attrs since it does the same as $props.

[gustojs]

Is that an "all or nothing" approach or can we declare some props and still let the component accept other props?

ANSWER: Yes, the rest of the props will be available as this.$attrs. I wasn't sure if it's only for functional components like in the example but turns out it's for stateful components too.

[yyx990803]

@gustojs anything not explicitly declared goes into $attrs.

[yyx990803]

This RFC is now in final comments stage. An RFC in final comments stage means that:

• The core team has reviewed the feedback and reached consensus about the general direction of the RFC and believe that this RFC is a worthwhile addition to the framework.
• Final comments stage does not mean the RFC's design details are final - we may still tweak the details as we implement it and discover new technical insights or constraints. It may even be further adjusted based on user feedback after it lands in an alpha/beta release.
• If no major objections with solid supporting arguments have been presented after a week, the RFC will be merged and become an active RFC.

[CyberAP]

Could this be limited to functional components only? As it was stated earlier props define a contract between parent and child. Leaving that out creates space for confusion. Especially when we already have $attrs. Have there been a huge request in leaving out props?

[thedamon]

@CyberAP I agree declaring props is preferable in most cases, but this change does not change best practices. It provides an interesting option in edgecases where being able to have all (or some) props in a bucket is convenient or more performant, and providing some alternate ways to pass data.

I don't think this feature changes that especially because these props are referenced differently ($props.foo vs foo), which maintains declaring props as the more natural way because it is "smoothest".

There could be an eslint rule to encourage declaring props as well.