AssignmentExpression in JSXAttributeName

[NekR]

It would be good to have ability to evaluate attribute name. For example:

<Component {attr}="value" />

Might be transpiled to:

Component({
  [attr]: "value"
});

Yes, this is es6 output because JSX spec extends es6 specs. Transpilers/targets which do not support es6, but only es5 might choose to not support this feature. But for others it might be useful.

Also, E4X support this feature and for me, it's reasonable to have it.

[RReverser]

Technically, this is currently supported via JSX spread like

<Component {...{[attr]: "value"}} />

but I totally agree that having short syntax for separate properties would be a great addition.

[NekR]

Just made little PR #22 for the case that all will agree with this feature.

@RReverser can you review it?

[sebmarkbage]

In general, I'm a little skeptical to adding more stuff until we can get more people involved in this spec. E.g. the people writing library alternatives to React, so that React isn't the only consumer of this spec. Also, more implementors such as TypeScript.

To make it more palatable to them it's important that the spec starts off as a minimal-viable-product. Other than that I think that this is probably a solid proposal.

[NekR]

@sebmarkbage Here I believe now is another consumer of JSX :-)

[RReverser]

@NekR I'm not sure I see benefits of inventing own babel-plugin-jsx over setting jsxPragma in Babel to own runtime.

[NekR]

@RReverser that is explained in blog-post, but in short, Babel emits React-specific calls even with changed pragma (traspiling there also is called React, not jsx, btw). Inlined output also is not very helpful since it's still React-specific and making another framework on top of that would be a hack. For example deku guys had same the thoughts about it.

JSX-IR just allows independent output which can be consumed by deku, Incremental DOM, whatever, etc.
"Give it five minutes", if you can, please.

[NekR]

@RReverser
See #29 (comment) and next comment.
/cc @sebmck

[RReverser]

Well, it's not really that specific and easy to write runtime that would just covert those calls into your own builders (instead of writing completely another transpiler plugin).

[NekR]

@RReverser well, what is a problem with separate compiler plugin? Also, why then react team is about to optimize their output and use inline object instead of functions calls? I believe there is performance value too.

Why all should stick to React infrastructure? I do not see benefits of using function calls at all, and especially React specific. Expect of that it's already implemented.

[RReverser]

@NekR I just don't see where is "stick to React infrastructure". Function calls are the sanest way of constructing, optimizing and modifying objects, and they're not React-specific at all, as soon as you can pass own runtime via jsxPragma. Of course, there is not much problems with separate compiler plugin, but that means that you stick with own support for JSX, and if/when JSX is extended with new node types, you have to maintain and add support for those new node types on your own instead of relying on central implementation.

[sebmck]

Function calls are good because they allow you to validate the input at runtime and produce useful stack traces.

[NekR]

@RReverser
Why is Babel central implementation and why then have the spec at all? Imagine Brendan Eich and Mozilla are saying -- why v8, let's stick to one central implementation, because otherwise you will need to maintain your own implementation. Isn't it sounds ridiculous?

[trueadm]

@RReverser Whilst function calls might conform to sanity when in the development stages they don't when at production stages. In the case of virtual DOM object construction they're simply constructor calls where the end output remains largely the same. Given this is being actioned by a transpiler rather than a human, it makes sense to optimise where possible. It's faster at a run-time level to pass back an object than it is to call repeated createElement functions – in fact, you're likely to see "Not optimized: Optimized too many times" from the V8 JIT compiler.

[NekR]

@sebmck it will be handled by the functions anyway, but just later. Stack traces point sounds fair, but there is always are trade-off between usability and performance. Function calls probably can be used in development mode, but it introduces so much complexity. With objects literals you do not need to have anything in views/templates/components scope since it's just object without direct dependencies.

[RReverser]

@trueadm Nothing stops you from writing a function that returns cached value, and in fact you'll get direct inlining in any modern JIT including V8, just as you do with compile-time inlining.