Improved If syntax including ElseIf support about jsx-control-statements

[jimfb]

This is a little odd because it would mean the expression doSomething(<If></If><Else></Else>) is legal but doSomething(<A></A><B></B>) (where A and B are components) is not legal. I'm not sure how I feel about control statements breaking the rules. I know our internal linters at Facebook would complain, not sure if the public linters have a check for adjacent JSX tags.

[texttechne]

Yeah, but we're already stretching this quite a bit.

• doSomething(<For of={[1,2,3]}><div /></For>) won't work although it look allright
• doSomething(<If></If><Else></Else>) would work although it appears to be wrong + IDE warnings
• doSomething(<If><div/><div/></If) is also possible with #31

[jimfb]

We're not stretching it, yet. Up to this point, we've remained consistent with JSX.

• doSomething(<For of={[1,2,3]}><div /></For>) WILL work - passing an array of elements to a function is perfectly valid/legal. http://jsfiddle.net/Lbxc53tL/
• doSomething(<If></If><Else></Else>) Yes, this is the one that concerns me a little. The choose is almost exactly the same, except with a transparent wrapper that groups the conditions together.
• doSomething(<If><div/><div/></If>) I agree, I have no complaint with this syntax, this is fine.

[texttechne]

Sorry, actually got the first two wrong:

• ok doSomething(<For of={[1,2,3]}><div /></For>) works, granted
• doSomething(<If></If><Else></Else>) WILL NOT work - just tested it and got: "Adjacent JSX elements must be wrapped in an enclosing tag": The JSX-Parser evaluates before the plugin, so it is not legal

About 3): I am making use of the array index to generate the key attribute. Do you see any problems there? The array index is not stable enough for <For> loops (according to this issue), but what about <If> statements?

[jimfb]

No problems, the index within an if statement should be stable.

[texttechne]

Cool, thanks a lot.

So if doSomething(<If></If><Else></Else>) is not legal, do you have any concerns left?

[jimfb]

Nope :P. Sounds like that pretty much kills this issue, right?

[texttechne]

Your issue or this issue about the suggested syntax?

[jimfb]

This issue, #32. If doSomething(<If></If><Else></Else>) is not legal at the parser level, that means all the variants are also not legal, unless I'm missing something.

• var x = <If></If><Else></Else>;
• return <If></If><Else></Else>;
• etc

right? Or am I missing something?

[jimfb]

I suppose this syntax is still doable if you require that it occurs within another tag. But if you're going to do that, you might as well just use a choose (which will always work and is more general... can be used within a function call, assigned to a variable, returned, etc)

[texttechne]

yeah right: All these cases are illegal. But I wouldn't regard this as devastating killer argument...

I think this syntax would be much better than choose. From experience, it just sucks to switch between <If> and <Choose>: Two APIs for the same functionality.

Above all this is what would be intuitively expected from a 'neat' if statement: If / ElseIf / Else.

You couldn't use If in combination with an ElseIf or Else at the root level, but that's equivalent to
<If condition={x}></If><If condition={!x}><If> which is also not possible.

[jimfb]

Yeah, I agree, not as devastating as I was thinking two posts ago, but it is pretty unfortunate. And yeah, I agree, choose is verbose.

FWIW, I'm not entirely oppose to the if-elseif-else syntax. Struts uses it (https://struts.apache.org/docs/else.html), and while I wouldn't use them as a shining example of good designers, I did find it more convenient than JSTL's choose syntax.

However, my intuition is to just use <If condition={x}></If><If condition={!x}><If> instead of introducing additional primitives. And use choose in advanced situations where adjacent Ifs aren't legal/practical.

[texttechne]

Wow struts, haven't had the pleasure ;-)

From a usage point of view, it just happens too often that you start with an <If> but end up with an <Choose>. And then you have to rewrite that which sucks.

Also <ElsIf> and <Else> are more readable than many <If> statements. And this library is not so complex that this additional API surface adds too much burden for the future.

Most simple but somewhat strange solution for the named examples would be:

var x = <Choose><If /><Else /></Choose>

[texttechne]

Alternatively <Choose> and <If>/<ElsIf>/<Else> can be supported...

Thanks for the thorough discussion. So let's see what @AlexGilleran and @vitalybe think!

[jimfb]

Surface area is also "how many tags and tag-props do people need to memorize" (or read about) in order to understand a piece of code. The way I see it, we need for (loops), If (simple logic), and choose (complex logical decisions). All three constructs are perfectly valid and generally applicable.

You are advocating for a fourth construct else/elseif (medium-complexity logical decisions) to fill the gap between if and choose. The proposed semantics deviate from the way XML/JSX work. It introduces edge cases like being unable to use it in certain situations due to the fact that it depends on adjacent tags. We just need to ensure the value outweighs the API surface area and cognitive complexity. IMO, when in doubt, don't introduce an API.

FWIW, I do like this syntax better than the existing if-else syntax.

I agree, good discussion. Keep up the great work! And thanks for contributing to this project! I know I appriciate it, and I'm sure @AlexGilleran does too :).

[AlexGilleran]

I definitely appreciate it.

I've enjoyed the discussion - I actually quite like the flat <If></If><Else></Else> syntax because it's neat, but it's not very XML - we'd have to be really careful to make sure stuff like <If></If>text!<Else></Else> is jumped on. It's better than the current <Else> and not any more abusive of XML conventions either.

To be honest I'd be happy to support both <Choose> and that, mainly because when it comes down to it this library is all about making functionally equivalent code look a bit neater, which is subjective - this allows users of JCS to decide what looks better for themselves. Does mean more work maintaining it though :(.

[AlexGilleran]

Pretty sure this is resolve by <Choose>, can reopen if someone disagrees.