[acemarke]

I'd still _loooove_ to have "prop punning", ie, shorthand passing of props based on local variable names equivalent to ES6 object literal shorthand:

    <MyList items selectedItem onItemClicked />

Doesn't seem too likely to happen at this point, though.

[jameslk]

While not as sexy, you can do:

    <MyList {...{items, selectedItem, onItemClicked}} />

There's a lot of "gets you most of the way there" hacks with JSX that will fill most needs. Where as you can imagine the incredible cacophony of screaming developers who maintain TypeScript, Preact, IDEs, etc. that would be incensed by breaking changes to JSX introduced just to solve some inconveniences.

[acemarke]

Trust me, I'm well aware of both of those facts :)

Doesn't mean the syntax _can't_ change . After all, the `<>` shorthand syntax for fragments was added via cooperation with the Babel and TypeScript teams, and the work on the new `jsx()` replacement for `createElement()` is going the same way.

[Gaelan]

That conflicts with HTML syntax, no? <input disabled /> is equivalent to <input disabled={true} />.

[acemarke]

Which is why the current JSX syntax uses that as a synonym for `disabled={true}`. Agreed that it matches HTML better, but having written an awful lot of `someLongVariableName={someLongVariableName}`, I sure wish I could stop repeating myself there.

[floydnoel]

I, too, find it ridiculous to repeat `foo={foo}` over and over again. So I use the spread operator with ES6 shorthand object syntax. Now it’s `{...{ foo }}`. No breaking changes needed!

[efrafa]

That would just be confusing.

What would happen with <input disabled /> then?

What if there is a global disabled var?

[tW4r]

I agree, I think <Element {prop} /> works better

[azangru]

I thought this style was generally disfavored? It's perfectly possible to pass `true` as a valueless prop (<MyComponent disabled />); and yet either the default typescript linter, or typescript itself (I never investigated) complains of this syntax.

[scns]

ReasonML works like that