Implement <Switch> statement about jsx-control-statements

[jimfb]

👍 I like the switch statement and optional default.

The fallThrough seems a bit ambiguous to me. Does the control flow "fall through" the case requirement (ie. fall from the previous case into this case) or does it "fall through" the bottom and into the next case statement? I honestly don't know which behavior you have in your mind, which makes me nervous because it means the API is potentially ambiguous/unintuitive and thus bad/confusing.

[texttechne]

Thanks for the input, haven't thought that this could be ambiguous.

So what's the "spec"? fallThrough should actually specify how to handle the break statement. So if a case is true and defines fallThrough=true this block as well as the next one is rendered, i.e. no break is rendered for this case.

My reasoning for naming that "fallThrough" instead of "break" (by default false) is to reverse switch's default behavior. Crockford categorised it as one of JS bad parts:

A common error in switch statements is to forget to place a break statement after each case, resulting in unintended fall-through. expects that the statement before the next case or default is one of these: break, return, or throw. (http://www.jslint.com/help.html#switch)

I don't think that anything is wrong with that fall-through behavior and that there are legitimate use cases for that feature if it wouldn't be turned on by default. So if we turn that off by default, it becomes a feature and perceived as feature, people (me included) tend to call that fall-through. See above quote or this SO answer for example.

So much for my reasoning and language use, it won't make the ambiguity go away for new users. Then again, I'm not so sure of this ambiguity...

Do you have an alternative in mind?

[AlexGilleran]

So you'd write something like:

  <case value={42} />
  <case value={41} fallThrough={true} />
  <case value={43} fallThrough={true}>
     This executes for 42, 41 or 43.
  </case>

?

I use that as a feature in JS as well but possibly we can do better? How would you feel about just being able to pass an array in the value instead?

[jimfb]

@AlexGilleran You don't want to pass in an array as the case value, because you would want it to be possible to use an array as the expression value. The only way you could differentiate (in general) would be to require that the case value always be an array, which would suck.

@texttechne Sometimes "less is more". I think the 95% use case is to break, so I agree that should be the behavior. However, I don't see a strong need/desire to add additional syntax/complexity to handle fall-through behavior. Users have a couple of options if they want multiple cases to execute the same code. They could copy-paste the code (for simple blocks, this is probably fine) or they could use a different structure.

For instance, @AlexGilleran's contrived example could be rewritten as:
<if condition={value === 41 || value === 42 || value === 43}>This executes for 42, 41 or 43.</if>

Anything you can do with fallThrough is still achievable through different constructs, so you only want to increase the API surface area if you think that the new construct will be used so frequently that it justifies the additional API surface area. I believe that providing fallThrough to cover the 5% case doesn't make sense, because it adds to the cognitive overhead and doesn't provide sufficient value. Combine with the potential ambiguity, I'd vote to just skip it. Keep in mind that it's always easier to add an API later than to remove an API (a lesson we continually learn the hard way with React core; deprecations are an order of magnitude harder than new features).

Upon further reflection, I'm convincing myself that the switch statement syntax does not justify it's own additional API surface area, since the construct's behavior is completely covered by the strictly more powerful choose API.

[texttechne]

@AlexGilleran Nice example! That highlights how repetitive this fall-through feature really is.

Array support would be nice, but we are restricted to build time transformations, so we don't know if the expression value is an array or a primitive. We can only differentiate between StringLiteral and JSXExpressionContainer (in Babel speak).

You don't want to pass in an array as the case value, because you would want it to be possible to use an array as the expression value.

@jimfb as with a proper JS switch, we could not compare arrays or objects - well, only for equality of reference. And being restricted to build time transformation, we couldn't do a proper deep equal in the background. Hence <Switch> would only support primitives.

In sum:

• <Switch>'s functionality is completely covered by <choose>
• no good API for fall-through feature (ambiguous and repetitive)
• fall-through feature is a rare use case (especially for templating)

At this point there is no argument for introducing this control statement.