If you know all the properties that you want to place on a component a head of time, it is easy to use JSX:
var component = <Component foo={x} bar={y} />;If you don't know which properties you want to set, you might be tempted to add them onto the object later:
var component = <Component />;
component.props.foo = x; // bad
component.props.bar = y;This is an anti-pattern because it means that we can't help you check the right propTypes until way later. This means that your propTypes errors end up with a cryptic stack trace.
The props should be considered immutable at this point. Mutating the props object somewhere else could cause unexpected consequences so ideally it would be a frozen object at this point.
The lesson learned is that you should be constructing all your props first and then passing them into the component.
In the early days of JSX you didn't have a way to pass a props object to your component, so you had to resort to a plain function call:
var props = {};
props.foo = x;
props.bar = y;
var component = Component(props); // Where did my JSX go?Now you can use a new feature of JSX called spread attributes:
var props = {};
props.foo = x;
props.bar = y;
var component = <Component {...props} />;The properties of the object that you pass in are copied onto the component's props.
You can use this multiple times or combine it with other attributes. The specification order is important. Later attributes override previous ones.
var props = { foo: 'default' };
var component = <Component {...props} foo={'override'} />;
console.log(component.props.foo); // 'override'The ... operator (or spread operator) is already supported for arrays in ES6. We're also pushing to get the spread operator for object properties in ES7. You can read the full proposal here:
Object Rest and Spread Properties
In fact, thanks to our JS transform pipeline, you can already use this in our code base as an experimental syntax:
var oldObj = { foo: 'hello', bar: 'world' };
var newObj = { ...oldObj, foo: 'hi' };
console.log(newObj.foo); // 'hi';
console.log(newObj.bar); // 'world';Merging two objects can be expressed as:
var ab = { ...a, ...b }; // merge(a, b)Why not <div props={props} />?
This reads more like the traditional attribute-value model of XML. However, it's semantics are a bit unclear. We don't actually want to allow you to set the props object itself. It's going to be a copy. It's also not setting the property named props.
Why not <div {props} />?
Again, this is not passing the props object through. We can't allow that. So therefore it's unclear where the copying happens in this case. It's also not consistent with the other spread syntax if you want to do the same thing in objects.
Why not <div ...props />? Why do we need curlies?
This becomes ambiguous for certain expressions such as <div ...x / 5 /> where you need lots of look-ahead to solve the ambiguity. We might be able to allow a small subset of expressions to avoid the curlies in all attribute expressions, but then it would be confusing when you need it and when you don't.
Why not <div ...{props} />?
This would be a reasonable but there is another use case for spread in JSX that might come up in the future... The children position.
<div> prefix {...children} suffix </div>
This would either be inconsistent in attribute position. We can't safely use the syntax <div>Hello...{children}</div> because ... is so frequently used in written language, preceding an expression.
Why not allow more features that JS allow in the object position?
You could imagine the {} escaping to JS and allowing anything that you can put in an object literal. Such as <div {get x() { }} /> or <div {x} />. The main reason we don't is because we want to separate the syntax that JSX allows and the semantics that it transforms to. For example, ... could be valid even if attributes are passed as arrays instead of objects.
Besides, we don't really support getters widely and it wouldn't necessarily make sense to allow a getter to be defined inline. <div {x} /> would be confusingly similar to <div x />. The first one transforms to { x: x } while the second one transforms to { x: true }. There's not much use for this feature beyond spreads.
Merge doesn't work, per se, but it's close. I'm on 0.13.3, and I was able to achieve what I wanted by just putting the spreads next to each other.
<Foo key={c.id} {...c} {...bar}/>I actually like this syntax just as much...