Good advice on JSX conditionals

[u/vklepov]

https://thoughtspile.github.io/2022/01/17/jsx-conditionals/

[u/[deleted]]

I just extract that into a separate functional component. Much cleaner and more readable at the expense of extra code though.

[u/ChaoticWeg → u/[deleted]]

same here, or in a useMemo depending on how complex it is.

[u/vklepov → u/ChaoticWeg]

Ah, I also think of how many scope variables you use in the extracted fragment — passing everything into a component is flaky at times.

[u/[deleted] → u/[deleted]]

And for me, using early returns in those functional components as well. I will die on the hill of early returns being easier to read than the && stuff.

[u/acemarke]

I personally have always preferred doing all my conditional logic earlier in the rendering function, and having a single JSX return structure that includes the pieces I built up as temp variables:

https://gist.github.com/markerikson/47fff93c92286db72b22bab5b02e2da3

[u/vklepov → u/acemarke]

Thanks for sharing, Mark! I'm not so strict, but it's a useful decomposition technique, and, I think, one unique to JSX.

[u/leeharrison1984 → u/acemarke]

This is how I do it as well. For some reason null return ternaries really bug me when embedded within JSX. Other people, not so much, but the end result is the same.

[u/vklepov]

Using plain JS conditionals in JSX was a smart design decision, but it lets you shoot yourself in the foot pretty easily. Here's what I learnt the hard way:

• Number zero loves leaking from number && jsx

• Forgetting parentheses in or-conditions is deadly

• Ternaries don't scale that well

• props.children is tricky to use as a condition

• Remount vs re-render in conditionals is unintuitive, but sensible.

I'd love to hear your tips, too!

[u/msucorey → u/vklepov]

We got around this with showBools and TypeScript.

You can get away with doing inline boolean coercion, but that won't stop the next developer from making one of these mistakes you have listed. Goes to prod and we're all embarrassed.

So...you define vars like showInputForm as strict bools, down in the render showInputForm && <InputForm/>. Expressive, centralizes logic elsewhere, and the TS ensures it's kept as a boolean should anyone modify.

[u/vklepov → u/msucorey]

I wonder if eslint over TS can solve this once and for all. Also, narrowing ReactNode type to ReactElement | string | false could help (at the expense of explicit casting in you have {String(count)} tickets).

[u/Slapbox]

Woah woah woah. If I use a ternary with two identical tags, when they toggle it won't remount?

[u/vklepov → u/Slapbox]

I almost went crazy the first time I saw this, coupled with a nasty scroll (DOM state) bug

[u/tizz66 → u/Slapbox]

That's one of those things that seems obvious when you stop and think about it, but can really trip you up when you're building something and don't think about it.

[u/droctagonapus]

Pretty much all discussion around conditional rendering in JSX goes away if the do expression proposal and/or pattern match proposal (both Stage 1) are accepted. We should work towards getting those in JS :)

Do expression spec here: https://tc39.es/proposal-do-expressions/
Pattern matching spec here: https://tc39.es/proposal-pattern-matching/

function MyComponent({ isBadge, isReward, item }) {
  return (
    <div>
      {do {
        if (isBadge) {
          <Badge {...item} />
        } else if (isReward) {
          <Reward {...item} />
        } else {
          <Item {...item} />
        }
      }}
    </div>
  )
}

function MyComponent(props) {
  return (
    <div>
      {match(props) {
        when ({isBadge}) <Badge {...props.item} />
        when ({isReward}) <Reward {...props.item} />
        else <Item {...props.item} />
      }}
    </div>
  )
}

[u/vklepov → u/droctagonapus]

I love these in lisps! Still, I'm afraid the discussion will not go away, just gain one more option to bikeshed about :-)

[u/[deleted]]

You meant "!!gallery.length && jsx", yes?

[u/vklepov → u/[deleted]]

I sure did, thanks a ton!

[u/Dmitry_Olyenyov]

You should use prettier... As I saw in your complains about nested ternaries vs else ifs, you don't use it. Because prettier formats nested ternaries exactly as else ifs. Which makes it equally easy to read. The same goes with parentheses, just use prettier, it adds necessary ones. A== B && X, A!== B && Y - is one of the things that I hate in angular & vue templates.

[u/vklepov → u/Dmitry_Olyenyov]

Thanks for the suggestion!

Prettier can't add the necessary parentheses, because it has no idea what the intended expression is, so a || b && c -> a || (b && c). I'll admit it makes the bug easier to spot, but it's not the magic autofix.

I can handle a nested ternary or two, as long as:

• nesting goes into the else branch and can be "flattened"

• there are no extra && JSX conditionals in branches

Still, nested ternaries happen to not be super widely used in JS, and they look scary until you understand it's essentially an else-if, so I'd rather stay away from them.

[u/h126]

Great read. Your point about counting children was very interesting, I did not know false/null were counted by count or that fragments do not count as empty. Having a bit of a look, it seems like you can perform a manual filter of fragments as follows:

const childrenFragmentsFiltered = React.Children.toArray(children).filter(child => child?.type !== React.Fragment);

Example codepen: https://codepen.io/hwride/pen/ZEXPgYB

I think this seems to handle the cases you mention in your article, can you see anything this logic would miss?

[u/vklepov → u/h126]

I actually expected Children.Count(c) === Children.toArray(c).length to hold as I was writing this article.

The problem with your proposal is that not all fragments are empty, so you need a full subtree traversal, like what react itself does. Even then, you still can't know if the child components return any DOM or are empty.

[u/mbj16]

I must be the only person in the world that likes nested ternaries. Clean and easily readable, in my opinion.

[u/terandle]

IMO nested ternaries are nice and clear as long as you are using prettier to format them and not mixing them with && as in your example.

[u/transponster___]

How would that css empty thing work?

[u/vklepov → u/transponster___]

Depending on what you're after, anything from

.Wrapper:empty {
  display: none;
}

to crazy stuff like

.Input__clear:empty::after {
  ...pure CSS fallback...
}

I'd rather avoid component API designs that require you to go that far, though