Discuss Conditional JSX Expression

[jimfb]

From @syranide

http://wiki.ecmascript.org/doku.php?id=harmony:array_comprehensions could this be something to consider for JSX? I.e. statement like syntax inside braces, more readable than ternary and various other hacks while still being very much like JS. <div>{if (x) <div />}</div>, etc.

[jimfb]

Continuing the discussion fragment in #28 (comment): Yes, I was implying statement like syntax, but not just in a JSX expression. I was proposing that all the JSX expressions BE statement syntax. So the presence of a JSX expression is equivalent to renderOutput += '<div>'. This is more inline with the way languages like PHP work. To be clear: I'm not claiming this is a better style, only that it's an interesting alternative, and naturally allows the if(foo) <div /> syntax that you were looking to achieve without breaking compliance with standard javascript.

With regards to use of non-standard javascript: Yes, the line is a little blurry. Especially as we add ES7 features before they're is agreement at the standards committees. But the difference is, imo, the answer to the question "What is the surface area of JSX?", and what is "other stuff". Unless we have some sort of statement syntax, the expression if(foo) <div /> doesn't make sense as part of ES6/7, and would therefore be part of JSX. However, if JSX were interpreted as a statement syntax, then the expression would be standard javascript and therefore completely legit, imo.

That's just my two cents. I encourage discussion on these points, and am always interested in exploring alternatives.

[syranide]

I was proposing that all the JSX expressions BE statement syntax. So the presence of a JSX expression is equivalent to renderOutput += '<div>'. This is more inline with the way languages like PHP work.

I see two big issues, it messes with implicit indicies in a way that expressions doesn't (because all children, null or not, increment the index counter too):

if (x) <A />;
<B />; // key becomes ".0" or ".1"

It's also super unintuitive behavior that only made sense in PHP because it's concatenation of partial strings, not hierarchies:

a(); // what happens to elements appended in this function?
function a() {
  b = <div />; // is this appended?
  b; // does this append it?
  // what if a() is called outside of render()?
}

Especially as we add ES7 features before they're is agreement at the standards committees.

Yeah ofc, I said that on the assumption that it will pass (no idea if it will), but array comprehensions probably aren't really relevant to this discussion. Anyway, my mine gripe is specifically with the ternary operator for conditionals, it seems like such a massive disservice to the readability of JSX and React, despite being such a common operation. Anything more complex than that is usually best hidden behind a function call anyway.

On a hunch, I would be perfectly happy with just:

<div>
  {if (x) ValueA}
  {if (x)
    ValueA
  else if (y)
    ValueB
  else
    ValueC
  }
</div>

No nesting or anything else. Again, arguable whether one should do it or not, but it's very limited in scope and I find it far preferable to the ternary operator (which is just symbol soup):

<div>
  {x ? ValueA : null}
  {x ?
    ValueA
  : y ?
    ValueB
  :
    ValueC
  }
</div>

[matthewwithanm]

I agree that JS's ternary isn't as ideal as but for the simple case you could just use JS's short circuiting logical operators, right?

<div>
  {x && ValueA}
</div>

It would be nice for JS to have if-else expressions (instead of statements) a la CoffeeScript et al for the ternary case but JSX isn't the right place to address that IMHO. I've just been breaking those things out into methods/other components.

[syranide]

I agree that JS's ternary isn't as ideal as but for the simple case you could just use JS's short circuiting logical operators, right?

That seems even worse to me, especially if you consider {x && y && ValueA} or {(x || y) && ValueA}, it stars becoming really weird real fast, even more so when things aren't as simple as x and y. Also, {0 && x} outputs 0 and you're generally messing with the actual value of children.

...but JSX isn't the right place to address that IMHO.

I guess that's the point of this discussion, there is definitely a point where JSX could go too far, but I also think there's a point where JSX doesn't do enough. Ternary operators weren't designed for this and so just because they can doesn't mean they should be used. Conditionals is a very common use-case so neglecting it for philosophical reasons seems odd.

Personally I also think there's a point in discussing how it should be, regardless of whether we do it or not (we can conclude what JS offers is a good enough approximation). To put it differently, you can say '{' expression '}' and shrug your arms, but the same argument could be applied to JSX too (just use calls/objects/arrays/etc) but most seem to agree that JSX is beneficial.

[jimfb]

@syranide Would you be happy with:

<If test={x}>
  <A />
</If>

It's a little more verbose, but the upside is that you would also preserve the hierarchical readability. Would that be sufficient?

[lionng429]

@jimfb how would you specify or / and condition with this? Though it's readable, it's on the other hand misleading as it takes the same syntax of components

[jimfb]

@lionng429 There are a couple of ways you could imagine specifying the else block. You could do <If test={x}>true<Else />false</If> or it could be implemented in other permutations like <If test={x}>true</If><Else>false</Else>. Doesn't really matter; those are details. The question for @syranide was if this syntax would be acceptable to him / would be an improvement over the status quo.

The fact that it looks like a component is intentional. Conceptually, you've just imported the "If" component, which renders the children iff the test condition is true. It achieves the goal (more readable conditionals) without muddying the javascript syntax in a non-standard way.

[syranide]

@syranide Would you be happy with:

<If test={x}>
  <A />
</If>

It's a little more verbose, but the upside is that you would also preserve the hierarchical readability. Would that be sufficient?

I'm not sure if I'm the ultimate authority on this, I'm simply a bit displeased with the current situation and hoping there is a better alternative :)

Anyway, not a fan, repurposing elements seems like a bad idea, you would never consider ifFunc(1 == X, () => { ... }); to be a good idea and those two seem like the same idea. Instinctively it also seems like it encourages more "lazy" practices (say <MyComp if={...} />). It also enables you to do x = <If /> which just seems like a bad idea (it's not a reason to dismiss, but it's a con). On-top of being rather cumbersome and noisy (and annoying to refactor into functions).

---

My view on this subject is that I really respect the hands-off approach JSX has, it introduces elements, end of story. That's great. However most languages (including JS) were not designed with deeply nested expressions, like JSX, in-mind. The only conditional expression operator (?:) available is a poor fit, it was intended for simple expressions (my interpretation). So it seems there is a vacuum introduced by JSX which the host language might not care about (I also mean this in a broader sense, what if you wrote components in C or w/e).

Intuitively it could make sense to have '{' statements '}' instead (i.e. wrap it in a lambda):

<div>
  {return Value}
  {return Cond ? A : B}
  {if (x) return <A /> else return 1}
  {
    var list = [];
    for (x of list) list.push(<Item name={name} />);
    return list;
  } // meeh, but it works (yes, you can use the normal helpers)
</div>

This solves every problem (I think?) while not intruding on the host language. The only downside is the mandatory and predominant return everywhere. So one could image introducing '{{' statements '}}' instead. So:

<div>
  {Value}
  {Cond ? A : B}
  {{if (x) return <A />; else return 1;}} // semicolons for completeness
  {{
    var list = [];
    for (x of list) list.push(<Item name={name} />);
    return list;
  }}
</div>

To me that actually seems kind of neat and unintrusive, instead of having to move all complex code out into separate functions you can now do it inline and later refactor it out if necessary. It doesn't intrude on simple expressions and the ternary operator can still find itself useful for the simpler conditionals.

One could also imagine replacing the '{' expression '}' grammar with a new grammar '{' expression_statement '}'. It could be defined as the if- and for-statement syntax but where instead of having statement blocks they have expressions (or rather expression_statement) which are implicitly returned. It's intrusive but it wouldn't really introduce unfamiliar syntax:

<div>
  {Value}
  {if (x) <A /> else 1}
  {for (x of list) <Item name={name} />}
  {for (x of list) if (x.visible) <Item name={name} />}
</div>

This syntax should be transpilable to statement syntax quite easily. But no doubt controversial, and the benefits are arguable when the '{{' statement '}}' would provide the same benefit with just some additional code.

I feel like '{{' statement '}}' doesn't entirely address conditionals in JSX, but perhaps it's good enough considering how little effort and unintrusive it is. It seems very much in line with the premise of JSX if you ask me, it simply acknowledges that not everything are expressions, statements sometimes makes sense too.

---

tl;dr The example below seems like it could be a reasonable compromise to me:

<div>
  {Value}
  {Cond ? A : B}
  {{if (x) return <A />; else return 1;}}
  {{
    var list = [];
    for (x of list) list.push(<Item name={name} />);
    return list;
  }}
</div>

[matthewwithanm]

...but JSX isn't the right place to address that IMHO.

I guess that's the point of this discussion, there is definitely a point where JSX could go too far, but I also think there's a point where JSX doesn't do enough. Ternary operators weren't designed for this and so just because they can doesn't mean they should be used. Conditionals is a very common use-case so neglecting it for philosophical reasons seems odd.

It's not a philosophical reason. It's a huge tradeoff in complexity, both for tools and users. Right now it's just "stuff in brackets are JS expressions." Easy for for everybody to understand. And adding a special grammar for within brackets could wind up being an even bigger nightmare when new stuff gets added to the language.

Personally I also think there's a point in discussing how it should be, regardless of whether we do it or not (we can conclude what JS offers is a good enough approximation).

So do I! I just don't agree that that's how it should be (:

I don't mean to be dismissive or shrug my arms. When I say that I don't think JSX is the right place to address this, I don't mean that I don't think it should be addressed. But this is a problem in all of JS. Have you considered putting together a proposal for the language?

[jimfb]

And adding a special grammar for within brackets could wind up being an even bigger nightmare when new stuff gets added to the language.

Agree. I'm also not convinced the {{ grammar would even be unambiguous; it certainly does require infinite lookahead to differentiate between an object definition and a statement definition. But the more important point is the one @matthewwithanm raised: The syntax would intrude on the language space of future versions/extensions of javascript.

A favorite quote from Sebastian:

It is our intention to claim minimal syntactic real estate... That way we leave the door open for other extensions.

FWIW: The component/element syntax is available today: https://github.com/valtech-au/jsx-control-statements (personally I'm a fan).

[syranide]

It's not a philosophical reason. It's a huge tradeoff in complexity, both for tools and users. Right now it's just "stuff in brackets are JS expressions." Easy for for everybody to understand. And adding a special grammar for within brackets could wind up being an even bigger nightmare when new stuff gets added to the language.

@matthewwithanm Yeah I'm not disagreeing that there are trade-offs for some approaches, but JSX has a purpose and if it's not 100% fit for that purpose we should evaluate if we can make it better.... that's why we have JSX to begin with, JSX is a monstrous trade-off for something which has barely quantifiable benefits, but we all agree it's worth it. So obviously it's not that binary.

But this is a problem in all of JS. Have you considered putting together a proposal for the language?

I don't see how it's a problem with JS. Sure you could extend JS with it but I'm not sure what I would use it for other than possibly for JSX expressions. That last one wasn't really a serious proposal though.

Agree. I'm also not convinced the {{ grammar would even be unambiguous; it certainly does require infinite lookahead to differentiate between an object definition and a statement definition. But the more important point is the one @matthewwithanm raised: The syntax would intrude on the language space of future versions/extensions of javascript.

@jimfb If you think of it in-terms of JSX {...} --> JS (() => ...)() then you'll see that JS fat arrow functions suffer from the exact same ambiguity, you disambiguate those with ({}). The transpiler is allowed to drop the generation of fat arrow functions for expressions because they serve no purpose.

But the exact syntax isn't my point, but whether or not JSX has shortcomings. My experience is that JSX works surprisingly well as-is today when you have the time to carefully plan and organize your components. That is a luxury. Being able to move fast, experiment and later refactor is important. This seems like a small price to pay for that flexibility.

[sebmck]

FWIW, Babel actually implements do expressions. With this it means that the original example of:

<div>{if (x) <div />}</div>

can be represented as:

<div>{ do { if (x) <div />; } }</div>

with a do expression.

Babel implements the correct completion records semantics and outputs simple code and deopts to an IIFE for code it can't explode into a single expression. You can play around with it in the REPL here.

IMO a more generic JavaScript solution (ie. do expressions) should be sought rather than adding additional complexity to the existing JSX syntax.