JSX sugar for object as props

[syranide]

Hopefully we'll get JSX namespacing soon for accessing components inside objects (#760). Then, technically, there is only one thing that JSX cannot do that vanilla JS can, using an object as props MyComp(myObject).

JSX is beautiful that's why I love it, MyComp(myObject, <Child />) is not, I would much rather do <MyComp {myObject}><Child /></MyComp> or whatever syntax you prefer. To be clear, I'm specifically and only talking about supporting an object, no additional properties.

It's still just sugar, but with this feature JSX is capable enough to do everything JS can, while still looking familiar and being more readable than its JS counterpart.

As I've mentioned before, I could take it upon me to implement this myself, it should be a relatively simple change.

[sebmarkbage]

Wow, you and jsx need to get a room. :)

The way I think about it, JSX is essentially named arguments and give us a static way to reason about those arguments. However, I also see JSX as an object initializer as much as a function call.

It could desugar into descriptions of the call rather than the execution.

{ type: MyComp, props: { foo: exp, children: [child] }, context: this }

None of this is really incompatible with your idea. Just providing context of different ways we think about it.

Out of curiosity. What kind of patterns are you using that make this syntax common?

A common one is building up props externally and then pass it to the component. Although it's more common to mutate props on the statements following instantiation. Another is passing props from one component into another unchanged MyComp(this.props) or merging MyComp(merge(this.props, { more: 'stuff' })). Each one has their own issues.

[syranide]

@sebmarkbage Haha.

My perspective on this is simply that it shouldn't have be a conscious decision whether to use MyComp(myObject) or <MyComp argA={myObject.argA} argB={myObject.argB} /> or <MyComp data={myObject} /> because I prefer to use JSX (in JS it isn't). I agree that JSX shouldn't be something JS isn't.

As for use-cases, I'm still mostly experimenting, but personally the most obvious ones are when I have to conditionally (more complex cases) decide on arguments or when there are too many arguments, being able to keep the logic out of the JSX makes sense (and assigning a lot variables individually may not be very pretty).

I've also talked to @vjeux and it seems that you rely on this yourself a bit internally too, for sending in objects as-is and thus occassionally have revert to JS for this. Surely that works and there's nothing wrong with it, I just find it odd not to want to use JSX for those cases too, if it's all sugar anyway.

If you have a different philosophy/direction for JSX, then I'm obviously not going to argue, but before I understand what that is, I'll try to push it/you as far as I can. :)

---

Spontaneous side-track: personally, I really want to choose JSX over JS because it looks and feels like HTML, and is more readable than JS because of the closing tags. My reasons only concern the function call and children, not the properties. The way we write the properties I really don't care as much about and that's where JSX (in my opinion) has lost some of the flexibility JS offers.

Not saying it's something you should do, but I could see myself adopting the follow style instead, I retain the full range of JS functionality but with enough of the visual familiarity I prefer, without hiding the truth about what's going on:

<MyComp {{name: object.name, size: 5}}></MyComp>
<MyComp {merge(moreFields, {name: object.name, size: 5})}></MyComp>

Or even:

<MyComp {name: object.name, size: 5}></MyComp>
<MyComp (merge(moreFields, {name: object.name, size: 5}))></MyComp>

As opposed to:

<MyComp name={object.name} size="5"></MyComp>
MyComp(merge(moreFields, {name: object.name, size: 5})

Something to think about least. :)

[jaredly]

I would like this as well. My use case is generally constructing the object beforehand.

[jordwalke]

>    <MyComp {{name: object.name, size: 5}}></MyComp>
>    <MyComp {merge(moreFields, {name: object.name, size: 5})}></MyComp>

@syranide I believe that was even part of the E4X spec that JSX was modeled after.

[sebmarkbage]

@jordwalke sure? I don't think so.

I like this proposal because it discourages mutation after initialization as a way to build up props. That should ideally be disallowed so that prop warnings can be issued earlier.

The only downside is that it prevents us from moving towards a named arguments or exploded arguments model instead of passing a props object.

[magalhas]

👍 One of the first things that I struggled to do when I started experimenting with React was on how to pass an object to a sub component using JSX.

[sebmarkbage]

Going to close this for this proposal: https://github.com/reactjs/react-future/blob/master/01%20-%20Core/08%20-%20Transferring%20Props.js#L30

The reason for this is that we're currently cloning props objects so you're not actually passing those instances anyway. This syntax clarifies that this gets merged in. It allows for sugar for merging in additional properties.

This also preserves the option of using a single object for descriptors (merging descriptor and props object). It also allow us to switch the semantics to be an object initialization rather than an arbitrary function call.

It's not quite on parity with plain function calls and if you're using it outside React that might be interesting. But this allow us to change the implementation of JSX if we need to.

This new syntax allows these to be used for spreading named arguments if that every became a thing.

[syranide]

Yep, I was pointed to that proposal recently, looks awesome 👍