-
Notifications
You must be signed in to change notification settings - Fork 545
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why do we need props? #110
Comments
From the vue composition api reference:
Also the props are on the context object so you could do |
i guess this is because |
@ycmjason In my imaginary example, I suggested using syntax as in prop. This example is not just listing the attributes that a component can accept but set up validation and data conversion rules. // my-component
{
attrs: {
max: { type: Number },
name: { required: true },
},
methods: {
method() {
this.$attrs.max // Number or undefined (string was converted to number)
this.$attrs.name // String (can't be empty)
this.$attrs.type // String or undefined (Because no rules are specified for converting this attribute)
}
}
} |
then you are mixing two different concepts? attrs refer to html attributes which can only be strings? where props are vue properties and can have different types? |
@ycmjason So, in my example, I suppose that there was no such thing as "html attributes" and "component props". I allow only one concept - "component attributes". Attributes play the role of props for the component. We can set validation or conversion rules for these attributes. Optionally, each component attribute can be rendered into a native html attribute. I understand that mixing these two concepts seems a bit dubious, but I do not see any major drawbacks |
We are aiming to stay compatible with Vue 2 with regard to what we call "attribute fallthrough behaviour". (See RFC #92) That fancy term means basically that all "component attributes" that are not explicitly marked as being "props" (through the Your propoal doesn't allow that as there's no distiction anymore and people would have to come up with their own re-invention of differentiating props and attrs. |
According to Render function signature change all
listeners
will be included inattrs
. Why not includeprops
intoattrs
too?We could extend all
props
settings such astype
,default
orrequired
toattrs
. An imaginary example:That way we would have a single point to get external data -
$attr
.But, why we need separate
props
andattrs
?The text was updated successfully, but these errors were encountered: