Best practice regarding conditional JSX

[AugustinLF]

There seems to be several schools regarding the way to write conditional JSX. React's documentation suggests ternary expressions or functions, there are packages using using conditional tags, such as jsx-control-statement.

I settled with ternary when there's not too much logic or when the components are not too big (I then fallback to functions), but ternary expressions can easily get hard to read, and the syntax/spacing really differs, a lot. You can find things without any () around elements, or with weird indentation, to things like that, which readable, feel a bit verbose:

 this.props.condition === 'blah' ? (
    <span>IfBlock</span>
  ) : (
    <span>ElseBlock</span>
  )

Do you folks have an opinion on that?

[ljharb]

Our current usage wavers between conditionally defining a variable above the jsx block (without any multiline ternaries whatsoever), or one of the following:

<div>
  {condition ? (<span />) : null}
  {condition ? (
    <div>
    </div>
  ) : null}
</div>

  {condition && (<span />)}
  {condition && (
    <div>
    </div>
  )}
</div>

The latter example looks cleanest, but it suffers from a footgun: if condition is zero, it will be toString'ed and rendered.

What would be ideal is if JSX had an operator like a ?? b which desugared to a == null ? a : b, but lacking that, and considering the footgun, I'm not sure what we should be recommending for JSX.

[ilan-schemoul]

What about do ?

[ljharb]

@NitroBAY since that's only a stage 1 proposal, and this guide only allows using stage 3 proposals and above, do expressions are not yet relevant - however, since it's an expression, it'd likely be treated the same as any other parenthesized expression.

[merlinstardust]

To avoid the footgun (excellent term and I'll be using it from now on, thank you), wrap the condition in Boolean (or do the !!, but I find Boolean(condition) more readable)

[ljharb]

I believe our eslint config requires ‼ over Boolean(), fwiw (if not, it should be). Boolean isn't as safe because I can do global.Boolean = function () { return false; } for example.

[NicholasTancredi]

!loading ? null : (
    <ActivityIndicator 
        size="large"
        color="red"
   />
)

Edit from ljharb recommendation:

!!loading && <ActivityIndicator 
    size="large"
    color="red"
/>

[ljharb]

@w0251251 that's fine! altho often people prefer to have the positive condition go first, leading to cond ? <blah /> : null, which is more awkward, which is why people end up at ‼cond && <blah />.

[NicholasTancredi]

Thanks ljharb, I'll be using this style from now on its much better.

return (
    <View>
        { !loading && <Text>Done</Text> }
        <Text>Something</Text>
        { 
            !!loading && <ActivityIndicator 
                 style={styles.activityIndicator}
                 size="large"
                 color="red"
            />
        }
    </View>
)

[benweizhu]

I always feel it a little bit difficult to read when logic code mix with pure HTML.
I would prefer to extract them into a function and use {{this.renderXXX()}}. Unless it's very simple piece of code like {condition ? (<span />) : null} or {condition && (<span />)}

What do you guys think?

[ljharb]

@benweizhu renderFoo methods are not a good idea; these should instead be new components.

In other words, if the logic is too complex to be appropriate inline, then it belongs in a separate component.

[benweizhu]

yeah, agree, just like what react official site said about conditional rendering. My theory is we need to extract the code that exposes too many details and wrap it with something make sense(like another component).

[njgraf512]

@ljharb, about your comment:

renderFoo methods are not a good idea; these should instead be new components.
In other words, if the logic is too complex to be appropriate inline, then it belongs in a separate component.

I agree with this and have seen how refactoring large components with multiple alternate render methods into smaller components has made code easier to reason about, and has also uncovered bugs that were previously unknown.

Other resources that speak to the (in)correctness of renderFoo methods that I've found include:

• The react docs themselves: https://reactjs.org/docs/thinking-in-react.html
• This medium article: https://medium.com/@colshacol/react-the-slavery-pattern-e58c1db3d7f

The reason for my comment here is that I'm working with a collaborator that feels that it should be ok to use multiple render methods within a component. Some questions for you:

• My collaborator referenced the ordering section of Airbnb's style guide, which lists "optional render methods" as a rationale for their use. Do you have any comment on that, or are you able to speak to the use of these methods within Airbnb?
• Are you able to provide any more information/anecdotes on the reasoning behind your comments quoted above?
• Do you know of any other good available resources/documentation that speak to this issue?

Sorry for all the questions, and don't feel compelled to respond as I know you are busy, but I appreciate any insight you can provide!

[ljharb]

@njgraf512 that's not in any way a justification of their use; it's saying that if you do use them, their ordering is specified. The official position of this guide is DO NOT use renderFoo methods. There are still legacy places inside Airbnb where we use them, but whenever the opportunity presents itself, we strive to refactor to SFCs.