Support for <{'Module'} {'key'}={'value'}>

[vjeux]

Right now JSX only supports desugaring for value interpolation <Module key={'value'}>. Would be nice to support interpolation for the module name and keys. E4X supports those interpolations.

I would also really like to support interpolation for arbitrary props. This would allow us to get rid of this.transferPropsTo which is a really unfortunate API in my mind.

<Module {this.props} overridenProp="vjeux" />

[sophiebits]

Interpolating the module name seems hard since you don't know whether it's in React.DOM or not and local variables can't be accessed by string name anyway.

Also related to #129.

[vjeux]

/** @jsx React.DOM */
var module = 'Module';
<{module} />

could be rewritten as

var module = 'Module';
(React.DOM[module] || eval(module))()

Not sure we want to do it that way but it would work :p

[vjeux]

But I was more thinking about module being a reference to an actual function.

var module = React.createClass({});
<{module} />

would be rewritten as

var module = React.createClass({});
module();

[jordwalke]

👍

We've thrown around a couple ideas for being able to forward several properties:

<Component *={entireProps} />
<Component {entireProps} />

Either way, a couple of interesting questions come up:

Does the position of props effect the semantics? Does the order that they are specified effect the precedence?

<Component {entireProps} overrideProp={something} />
<Component defaultedProp={something} {entireProps} />

If so, then would it be transformed into:

Component(merge({defaultedProp: something}, entireProps, {overrideProp: something});

I like the end result. The only tradeoff to consider is that now our transform is becoming more than a lightweight, line-for-line, non-opinionated one. It might even depend on some runtime library to do the merging.

The <{expression} prop="hi"/> seems a little more straightforward.

[zpao]

Get rid of the interpolation in that last example and that's exactly what we have today… if The transform doesn't see something from a hard coded list, it expects a variable in scope.

Also, I will say no to any transform that puts eval into code :)

You could always do something like this:

var el = condition && React.DOM.div || Rect.DOM.span;
<el prop>{whatever}</el>

[vjeux]

hides It didn't occur to me that I could just to <module />

Christopher "vjeux" Chedeau
Facebook Engineer
http://blog.vjeux.com/

On Jul 4, 2013, at 1:33 PM, Paul O’Shannessy notifications@github.com wrote:

Get rid of the interpolation in that last example and that's exactly what we have today… if The transform doesn't see something from a hard coded list, it expects a variable in scope.

Also, I will say no to any transform that puts eval into code :)

You could always do something like this:

var el = condition && React.DOM.div || Rect.DOM.span; 
<el prop>{whatever}</el> 

On Jul 4, 2013, at 1:04 PM, "Christopher Chedeau" <notifications@github.commailto:notifications@github.com> wrote:

But I was more thinking about module being a reference to an actual function.

var module = React.createClass({});
<{module} />

would be rewritten as

var module = React.createClass({});
module();

—
Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v1/url?u=#158.
—
Reply to this email directly or view it on GitHub.

[jordwalke]

@zpao: There may still be value in allowing interpolation for the tag name, but I don't know how we would enforce that the closing tag matches!

  <{loggedIn ? LoggedInView ? LoggedOutView}>
     Children Here
  < ...  />  //  (What do we require here!?)

[zpao]

@jordwalke There's definitely value, but it comes at the cost of making JSX harder to understand, and I think that cost is too high.

And that case is so easily re-written to

var component = loggedIn ? LoggedInView : LoggedOutView;
<component>...</component>

that it hardly seems worth any complexity.

[petehunt]

So I am very concerned about adding complexity to JSX just for the sake of syntax. We need to keep it dead simple, IMO, unless we need to add expressive power.

I think that forwarding multiple properties is a useful use case, and could be desugared as an extra param to React.DOM.*.

[vjeux]

Let's close this out. If we need special keys we can always fall back to non-JSX.