Choose / Switch syntax instead of ElseIf and Else

[texttechne]

Considering the nesting of <ElseIf> and <Else> they're just markers and cannot be indented automatically by IDE's. Correct indentation would look like this:

<If condition={x}>
  IfBlock
  <ElseIf condition={y} />
  ElseIfBlock
  <Else />
  ElseBlock
</If>

So what about a choose statement (JSP style):

<choose>
  <when condition={x}>
    IfBlock
  </when>
  <when condition={y}>
    ElseIfBlock
  </when>
  <otherwise>
    Else
  </otherwise>
</choose>

Or (misusing) switch style:

<switch>
  <case condition={x}>
    IfBlock
  </case>
  <case condition={y}>
    ElseIfBlock
  </case>
  <default>
    Else
  </default>
</choose>

Maybe we should reserve the use of the switch statement instead of "abusing" the syntax. On the other hand we could also allow for an optional parameter for switch which allows exactly that, e.g. expression.

<switch expression={x}>
  <case condition={12}>
    IfBlock
  </case>
  <case condition={"Never mind"}>
    ElseIfBlock
  </case>
  <default>
    Else
  </default>
</choose>

In any case I would tend to make otherwise / default optional, so that users are not forced to switch between if/else and switch syntax. Implementation-wise we would simply make use of the ternary operator. @AlexGilleran what do you think?

[AlexGilleran]

My opinion: the choose block or something with those semantics is the best choice for else/if... I don't really like how the first one works with else/if, it's a bit messy. Just as long as we can preserve backwards compatibility with the current syntax and add this as another way of expressing it.

[texttechne]

I'm really not sure how to go about this API. IMO and at first glance the cleanest choice would be to only support <If> as standalone statement without <Else>, while <Choose> / <Switch> handle the other cases (of course, staying backwards compatible remains a core value, I'm just speaking about the ideal API, not about dropping support for <Else>). But this approach isn't ideal either.

On the one hand choose or switch have the following pros:

• correct nesting and therefore correct indentation by IDE's
• simplified implementation

On the other hand we would introduce two idioms which solve the same thing. So the cons are:

• As user I expect <If>, <ElseIf> and <Else> as basic control statements, but the last two or the last one are not supported
• If I start my implementation with an <If> and now need to add an <ElseIf> / <Else>, then I'm forced to switch to <choose> / <switch> syntax, which is just plain cumbersome
• My personal experience with JSP's and XSLT - where you have to use <choose> - is not that good: It just feels clumsy to write that stuff

In any case, let's start a discussion. We shouldn't rush this.

[texttechne]

Trying to pull in some people and their opinions: @justafish @helarqjsc @vitalybe (who opened the issue about elseif) and @jimfb (who appears to watch over this lib)

[texttechne]

Some research. Currently we're using Handlebars style syntax, although Handlebars doesn't support elseIf (if I'm not mistaken):

{{#if x}}
    IfBlock
{{else}}
    ElseBlock
{{/if}}

JSP (or JSTL to be more precise) has to handle this differently, because it's based on XML:

// no elseIf or else supported
<c:if test="${x}">
    IfBlock
</c:if>

// within choose the else block (otherwise) is mandatory
<c:choose>
    <c:when test="${x}">
       IfBlock
    </c:when>
    <c:otherwise>
        ElseBlock
    </c:otherwise>
</c:choose>

So depending on the background, different approaches have been taken. String based template languages like Handlebars implement what any developer would expect, while XML based templating languages need to adhere to correct nesting rules, which forces them to use the choose stlye.

JSX tries to emualte XML, so it fits the second category. However, since it transpiles to JS it is not confronted with the same restrictions.

My current thinking is to support both styles, knowing how cumbersome the choose style is.

[vitalybe]

"choose" syntax looks good to me and I love the fact it makes indentation logical again.

To make sure, the idea is that if one condition is true, the others wouldn't execute even if their condition would also resolve truthfully? E.g, this:

<switch>
  <case condition={true}>
      <div>1</div>
  </case>
  <case condition={true}>
      <div>2</div>
  </case>
  <default>
      <div>3</div>
  </default>
</choose>

Would only generate a single <div>1</div>.

[texttechne]

Sure, it should and will behave as JS behaves. In any case it's going to be transformed into a nested / chained ternary operator. For your example: true ? <div>1</div> : true ? <div>2</div> : <div>3</div>

Are you also comfortable with choose | when | otherwise? I think that we should reserve switch | case | default for real switch statements.

Thanks for your feedback.

[vitalybe]

The "choose" syntax is fine. Better option than switch.

On Wed, Jan 13, 2016, 21:28 texttechne notifications@github.com wrote:

Sure, it should and will behave as JS behaves. In any case it's going to
be transformed into a nested / chained ternary operator. For your example: true
?

1

: true ?

2

:

3

Are you also comfortable with choose | when | otherwise? I think that we
should reserve switch | case | default for real switch statements.

Thanks for your feedback.

—
Reply to this email directly or view it on GitHub
#26 (comment)
.

[jimfb]

I'm finding myself preferring the choose syntax also 👍

[texttechne]

See #32 for the better syntax.