Skip to content
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

Closed
cawa-93 opened this issue Jan 9, 2020 · 6 comments
Closed

Why do we need props? #110

cawa-93 opened this issue Jan 9, 2020 · 6 comments

Comments

@cawa-93
Copy link

cawa-93 commented Jan 9, 2020

According to Render function signature change all listeners will be included in attrs. Why not include props into attrs too?

We could extend all props settings such as type, default or required to attrs. An imaginary example:

{
  attrs: {
    modelValue: { type: Number, default: 0 },
    name: { type: String, required: true },
  }
}

That way we would have a single point to get external data - $attr.

someMethod() {
    this.$attrs.class // work with html attribute
    this.$attrs.someProp // work with component prop
    // etc.
}

But, why we need separate props and attrs ?

@davidbernegger
Copy link

davidbernegger commented Jan 14, 2020

From the vue composition api reference:

There are a number of reasons for placing props as a separate first argument instead of including it in the context:

  • It's much more common for a component to use props than the other properties, and very often a component uses only props.
  • Having props as a separate argument makes it easier to type it individually (see TypeScript-only Props Typing below) without messing up the types of other properties on the context. It also makes it possible to keep a consistent signature across setup, render and plain functional components with TSX support.

Also the props are on the context object so you could do const { individualProp } = toRefs(context.attrs.props) etc. if you wanted

@ycmjason
Copy link

i guess this is because attrs is probably always strings? whereas we can specify types in props?

@cawa-93
Copy link
Author

cawa-93 commented Jan 20, 2020

@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)
    }
  }
}

@ycmjason
Copy link

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?

@cawa-93
Copy link
Author

cawa-93 commented Jan 21, 2020

@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

@LinusBorg
Copy link
Member

LinusBorg commented Jan 22, 2020

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 props: option) will be added to the component's root element as HTML attributes. If you don't want that, set inheritAttrs: false and manually bind $attrs to another element.

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.

@cawa-93 cawa-93 closed this as completed Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants