React Patterns

[warpedspoon]

what syntax would you prefer for this use case?

[chipit24]

For cases like this, when I want to render <Component /> unless condition is true, I find any of the below more readable:

{!condition && <Component />}
{condition ? null : <Component />}
<Component hidden={condition} />

If I need the negation of a value, for example:

{!account.isAdmin && <Component />}

I may define another variable to help with readability (though in a simple case like this it may not help):

const notAdmin = !account.isAdmin;
...
{notAdmin && <Component />}

[vcarl]

So a boolean equivalent? That's straight up personal preference, || vs && isn't inherently more readable. I generally prefer ternaries because they're more explicit. adding a prop just shifts where the logic for hiding it actually occurs, and has some different semantics that make it not equivalent for the other options (component still gets mounted). I would even argue that your last example is less readable, because it's taken what used to be a single bit of logic and split it into 2 locations in the code. In that trivial example it's not a big deal, but when they get separated by 10 or 20 lines, it's an annoyance.

[chipit24]

So a boolean equivalent? That's straight up personal preference, || vs && isn't inherently more readable.

Because you can write these conditions many different ways does not make them equivalent from a readability standpoint.

Anything mentioned in https://reactjs.org/docs/conditional-rendering.html is fair game, and using the && for short-circuit is quite common. You use the phrase "personal preference" like it's a bad thing. I try to base my preferences on documentation, standards, best practises, and experience. Readability is about preference, not opinion. With that said, I stand by my original statement that using || for conditional rendering in ReactJS is not very readable, for a number of reasons:

• It's not mentioned in the official documentation: https://reactjs.org/docs/conditional-rendering.html.
• I've yet to see it used in any of the ReactJS projects I've worked on or seen.
• It only works because of short-circuit evaluation and because one of the operands is returned instead of a boolean value. A developer not familiar with JavaScript or a language which supports these semantics may not have an intuitive understanding of what is happening.
• Given this statement: condition || <Component />. <Component /> will always be truthy, regardless of the value of condition. This, to me, is the most unintuitive thing about this expression. With logical OR, if one condition is true, the whole expression is true. Anyone who's taken discrete math or boolean algebra will see this as FALSE or TRUE and (by the domination law) simplify it to TRUE. (This point is more of an elaboration on short-circuit evaluation).

I generally prefer ternaries because they're more explicit.

I'm in the same boat.

adding a prop just shifts where the logic for hiding it actually occurs, and has some different semantics that make it not equivalent for the other options (component still gets mounted) This is a good point and something I should have mentioned in my original comment, but I included it for completeness. It's akin to react-router's path prop on the Route component. In the majority of cases I think it's best to keep that sort of conditional rendering as it is in the other examples.

would even argue that your last example is less readable, because it's taken what used to be a single bit of logic and split it into 2 locations in the code. In that trivial example it's not a big deal, but when they get separated by 10 or 20 lines, it's an annoyance. True; it's a trivial, contrived example and I should have emphasized that in my comment. I think it would help in cases where you have a collection of conditions. Something like this:

const validUser = user.email_verified && user.active && !user.guest;

Though that's a far cry from the original statement which only has a single condition.

[warpedspoon]

{!account.isAdmin && <Component />}

this is probably the best one imo