RFC: Remove <If>

[leebyron]

I think <If> and <Else> might be a distraction from the value of <For> and I'm considering remove it. They're also potentially helpful for clearer syntax compared to {condition && <Node />} but have some real drawbacks as well.

Perhaps we should consider including them in a react-conditionals library?

[leebyron]

cc @manuelbieh - Presumably <Choose> would live with <If>?

[superhawk610]

I believe some of the syntactic clarity <If> aims to bring is lost in the closing tags inherent in XML/JSX structure. In traditional code this isn't an issue since } isn't visually intrusive. The nested structure is also a bit distracting. Compare the following:

if (condition) {
  // do something
} else if (anotherCondition) {
  // do something else
} else {
  // do another thing
}

<If test={condition}>
  {/* do something */}
  <ElseIf test={anotherCondition}>
    {/* do something else */}
    <Else>
      {/* do another thing */}
    </Else>
  </ElseIf>
</If>

Traditional JS blocks are visually sparse and shift focus to their contents, while XML tag blocks are a bit more visually weighty and thus distracting.

The only real drawback of guards ({condition && <Element />}) is they will render the string value of condition (eg - 'false') in some contexts. However, this is rather trivially solved by using the slightly longer ternary form {condition ? <Element /> : null}. Are there any other drawbacks to this format?

[leebyron]

Thanks for talking through it with me!

React actually has built in support for not rendering null or false as a string because of this exact pattern, so you wouldn't even see 'false' render.

I think understanding that boolean and && doesn't result in a true or false value but instead evaluates to the first non-falsey value is a weird Javascriptism for new comers to the language, but I agree that it's terse enough that it's worth learning. Generally I like ternary more than most, though I think ternary intermixed in JSX is often ugly.

I do think that simple uses of <If> are syntactically clearer, but I certainly agree that complex blocks of if/else quickly get less clear. The relative value add is just far less than <For>, which is why I'm thinking of ditching them from this lib

[superhawk610]

Well said. I think the relatively small value vs <For> is definitely the strongest reason for the change, focus is important.

[leebyron]