Warn against duplicate props/data fields

[yyx990803]

Problem

Currently the props are merged with the instance's own data, which has a few problems:

1. Both data and props can declare the same property name. The order and priority of the merging is not clear. Should a prop overwrite the field with the same name in data? Or the other way around? Currently, the props' initial values are available inside data functions, but the same field returned in data gets overwritten by the prop.
2. Once merged, it's not clear whether a component property is its "private" state or a prop that is passed down from (and thus can be changed by) the parent, unless you go and check the component's props declaration.

Proposal

Move props into its own name space, for example this.props. This avoids the merging problem (we can either make props a reserved field or make it $props) and makes it explicit that something is a prop that is obtained from outside the component.

Throw a warning if the user defines duplicate fields in data and props.

[kazupon]

👍
That sounds great !!
I hope especially to improve props namespace issue.

[dgerber]

Calling it $props would make clear that it's reserved.

[Mat-Moo]

How will this work with 2 way binding? At present I send a prop (which can be blank) and my data defines defaults and this works nicely. By separating them I would need to merge defaults with the prop data? Or create the correct data structure before creating the component (But I'm trying to make the component responsible for the data not the app). Make sense?

[yyx990803]

@Mat-Moo not sure if I get what you mean. You can declare defaults for props directly:

props: {
  a: {
    type: Number,
    default: 123
  }
}

[Mat-Moo]

Hmm I'm using v-repeat on an array to create components so data comes in anyway so maybe irrelevant.

[mark-hahn]

In functions, vars passed via parameters and local variables are in the
same space. Vue should stay as it is.

On Sun, Aug 16, 2015 at 10:04 PM, Evan You notifications@github.com wrote:

Problem

Currently the props are merged with the instance's own data, which has a
few problems:

Both data and props can declare the same property name. The order and
priority of the merging is not clear. Should a prop overwrite the field
with the same name in data? Or the other way around? Currently, the props'
initial values are available inside data functions, but the same field
returned in data gets overwritten by the prop.
2.

Once merged, it's not clear whether a component property is its
"private" state or a prop that is passed down from (and thus can be changed
by) the parent, unless you go and check the component's props declaration.

Proposal

Move props into its own name space, for example this.props. This avoids
the merging problem (we can either make props a reserved field or make it
$props) and makes it explicit that something is a prop that is obtained
from outside the component.

—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1166.

[mark-hahn]

Would this add more syntax to things like v-show? How about mustaches?

One of Vue's biggest features is its simplicity. I don't see how this proposal has enough benefit to excuse the added complexity. Things like removing $add are great.

"perfection is attained not when there is nothing more to add, but when there is nothing more to remove." - Antoine de Saint Exupéry

[yyx990803]

@mark-hahn Yes, this would make your template a bit more verbose. It's a tradeoff between conciseness (note - not necessarily simplicity) and explicitness. A component is stateful and its state can change over time - this is different from, say, a pure function call. It could be helpful to clearly know which part of the state is external and thus can change without the component itself doing anything.

That said, I'm also not 100% sure on this proposal yet. Would love to get more feedback from others.

[mark-hahn]

It could be helpful to clearly know which part of the state is external and thus can change without the component itself doing anything.

Objects passed into functions can also change without a function's help. You can't tell an object from a string using the syntax. Adding syntax for that, like hungarian notation, would be horrible.

Adding scope meaning to variables using syntax is a slippery slope. Should vars passed in to a function look different than local vars which look different than closure vars which look different than global vars?

[Mat-Moo]

I'm still not sure on this... When using 2 way bindings would it be data or a prop?

[gamperl]

In my opinion Vue is one of the best frameworks I've ever seen because of its simplicity. Moving the params in its own scope, would make it's structure more complex. Why not show a warning if there is a param and a data property with the same name?