4 Ways to Render JSX Conditionally in React

You'll need to USE this custom hook anyway inside your component, isn't it?

Those are two different things, you can simplify as much as you can the functions, apply SOLID into them and extract functions from components, but a component itself will probably need any hook (being custom or not) and some presentation logic.

It's common to use this pattern in Next JS, specially when you use SSR to avoid client-server missalignments:

if( !someProp ) return null;

While it's not so common in React, is also perfectly valid as defensive programming technique when a prop is required for a component to render properly.
It's placed at the beginning of the component, pretty understandable and suits any case in which a default prop value is not beneficial or, if you've preference for other patterns, we can say it's beneficial whenever a ternary would be worse.

Also consider that:

function Test({ userName }) {
  return userName && (<p>hi {userName}!</p>);
}

Using this pattern (or similar ones) we receive undefined as return value whenever Test component either doesn't receive a prop or the prop evaluates to falsy.

So if you do something like:

/**
 * Returns a message depending on the quest result
 * @param {boolean} winner
 */
function QuestResult({ winner }) {
  return winner && (<p>You {winner ? 'WIN' : 'LOSE'}!</p>);
}

export default function Whatever() {
  return (
    <div className="results">
      <h1>Quest Finished</h1>
      <h2>Result</h2>
      <QuestResult winner={false} />
    </div>
  );
}

You'll get no message if you lose because winner is false, so it can cause non desired side effects.
So it's better to stablish that pattern as default one (from my experience):

/**
 * Returns a message depending on the quest result
 * @param {boolean} winner
 */
function QuestResult({ winner }) {
  if( typeof winner !== 'boolean' ) return null;
  return <p>You {winner ? 'WIN' : 'LOSE'}!</p>;
}

Of course you can do the same condition with a ternary:

/**
 * Returns a message depending on the quest result
 * @param {boolean} winner
 */
function QuestResult({ winner }) {
    return typeof winner !== 'boolean' ? <p>You {winner ? 'WIN' : 'LOSE'}!</p> : null;
}

but some components grow inevitably so they will become less readable plus this way you can control the condition easily and not having it coupled to the main return of the component. Easier to spot in PRs also!
Just look at this super simple example, we get a nested ternary here.
Is it worthy to decouple the message on a function getResultMessage(winner) or is better to use the other pattern?
And we even considered the hooks in the example above.

export default function MyComponent(props) {
  if( !props ) return null;
  // effects, states, whatever
  return <Whatever props={props} />
}

In this case nothing will be executed if props is not set (or falsy)

export default function MyComponent(props) {
  // effects, states, whatever
  return  props ? <Whatever props={props} /> : null;
}

In this one they will be (What a waste, huh?)

Really good points you bring up.

Just on one of them:

I was talking about "defensive programming" when I said that you should take that as a sign something should be worked on. If you need to avoid passing something because it could break stuff, then maybe make that stuff more stable? The previous example could avoid the "if" altogether if the Example component was able to receive someProp optionally, but because is required we had to write all that "defensive" code.

In most of the projects I work on, I need to do a lot of “progressive enhancement” on more monolithic systems (which inherently come with a number of restrictions/limitations/requirements). I’m often having to server-side render component data as Objects on the window global and then ingest them when my components conditionally render. Because I can never guarantee the stability of that data, I sometimes (not all the time) need to rely on the early return pattern to ensure the stability of the component.

Sometimes it’s because a CMS author has used a few unescaped characters and broken the Object (which we always do our best to sanitise, regardless). Other times a regression issue might cause the data Object to be malformed when it renders. But due to the nature of the environment, there is sometimes no way to make the data source “bullet proof”.

In my experience, when you can’t guarantee the existence and stability of your props, the early return pattern helps to maintain the stability of your components.

If you use a conditional return at the beginning of your function you can prevent everything else to execute, useEffects, useStates, whatever custom function and so on so this pattern is very used TBH, can't see the issue with it, it's pretty understandable, and useful in tones of different architectures. 🤷🏻‍♀️

Cheers for those library links! I haven't used them before, but they look really intriguing.

Agree that often you see the "right now" solution instead of the "right" solution (and I mean "'right' solution" very loosely, in that there is no one way to skin a cat).

Sometimes the competing budget, timeline, and plethora of other nagging responsibilities prevents us from taking the time think through these logical issues and refactor with leaner, more readable code, for sure. On the other hand, while some might find an early return more verbose, requiring more concentration to read, I feel they can still be as robust as any other logic that performs a similar function.

How great that all of this good discussion on programming patterns has spiralled out from a post on conditionally rendering JSX! 😄