Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
vjeux opened this issue Jul 4, 2013 · 10 comments
Closed

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

vjeux opened this issue Jul 4, 2013 · 10 comments

Comments

@vjeux
Copy link
Contributor

vjeux commented Jul 4, 2013

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
Copy link
Collaborator

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
Copy link
Contributor Author

vjeux commented Jul 4, 2013

/** @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
Copy link
Contributor Author

vjeux commented Jul 4, 2013

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
Copy link
Contributor

👍

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
Copy link
Member

zpao commented Jul 4, 2013

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
Copy link
Contributor Author

vjeux commented Jul 4, 2013

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=https://github.com/facebook/react/issues/158%23issuecomment-20491964&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=laHZhPsrTTGL9mHVyUC%2BICFnZxZCH4LNzfo%2BOgrHdsw%3D%0A&m=KttA727Vz3FtUgsPfrPNaCG0eW8%2BZ%2B%2Fq0%2BbMKE21%2BV0%3D%0A&s=c0ff6edc3252a081018b2bbe89a33b1df3a98154698611e145121ab7db8de7d2.

Reply to this email directly or view it on GitHub.

@jordwalke
Copy link
Contributor

@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
Copy link
Member

zpao commented Jul 5, 2013

@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
Copy link
Contributor

petehunt commented Jul 5, 2013

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
Copy link
Contributor Author

vjeux commented Dec 9, 2013

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

@vjeux vjeux closed this as completed Dec 9, 2013
bvaughn pushed a commit to bvaughn/react that referenced this issue Aug 13, 2019
Add a stress test for tree traversal
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants