4 Ways to Render JSX Conditionally in React

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

If you do:

if (!someProp) return null;

useHooks();

return <Example someProp={someProp} />;

It's the same as doing:

if (!someProp) {
    return null;
} else {
    useHooks();

    return <Example someProp={someProp} />;
}

Both have the problem that you're optionally calling hooks, so both are going against the rules of hooks. So in either case you need to call hooks first and then return, so the actual "versus" is:

useHooks();

if (!someProp) return null;
return <Example someProp={someProp} />;

// vs

useHooks();

if (!someProp) {
    return null;
} else {
    return <Example someProp={someProp} />;
}

// or ...

useHooks();

return someProp : <Example someProp={someProp} /> : null;

So in the case of hooks, the early return is not helping at all, is pretty much the same, just with a different style (which I stated before, I like less than just using a ternary).

While it's not so common in React, it is also perfectly valid as defensive programming technique when a prop is required for a component to render properly.

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.

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.

I've already said it in several comments, but I'm not in favor of short-circuiting (not just in JSX, but anywhere). It's hacky code and it should be avoided. A ternary is my default solution for code like that, but also I use default values or nullish coalescing when needed:

const Test = ({ username = "Guest" }) => <p>Hi, {username}!</p>;
// or
const Test = ({ username }) => <p>Hi, {username ?? "Guest"}!</p>;

Also that QuestResult component has a short circuit just because of reasons, it should be written like this:

/**
 * Returns a message depending on the quest result
 *
 * @type {import("react").FC<{ winner?: boolean }>}
 */
const QuestResult = ({ winner = false }) => (
    <p>You {winner ? "WIN" : "LOSE"}!</p>
);

So you don't need to do an early return there, neither you need the nested ternary. As I said, when you think: "Hum! I could use an early return here", that generally means you need to fix something else. You might argue "but, my function is rendering that p depending on if winner was passed as a boolean or not", and my argument would be: If that is optionally rendered, then you should have other property for that (like hidden or visible) so that you don't have two unrelated pieces of logic (showing the message, and the content of the said message) coming from the same prop.

Your last example I addressed at the beginning of this comment, but with either approach, you should always run effects, so early return doesn't solve much (it might even potentially cause a bug).

Early return are almost always presented as a really "cool hack", but is only one style for doing things that, at least from my point of view, only makes the flow of the function less readable with no real benefits.

Thread

Thread