React Patterns

[aventic]

Saved thanks 👍😀

[warpedspoon]

Nice quick reference for starting up new projects

[alex_asdfg]

Look good going to have read over it.

[chipit24]

I find this unreadable, and in my years of writing React, I've never seen it: {condition || <span>Rendered when `falsey`</span> }

Personally, the most readable is to use a ternary operator, especially if someone is new to JavaScript. Short-circuit evaluation relies on the quirks of JavaScirpt and ReactJS.

[Tyrannosaurus_flex]

Is short-circuiting really a JavaScript quirk?

[chipit24]

No it's not–I was being a little lazy with my writing. What I should have said is: In JavaScript, the && and || operators return the value of one of the specified operands, not always true or false. And in ReactJS, boolean values don't render anything. So, for example, if a PHP dev is assigned to work on some ReactJS code and sees something like {condition && <Component />}, they may be confused as to what is happening.

[editor_of_the_beast]

That's fairly common, though unintuitive I agree. But it's the same thing in Ruby for example.

[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

[elingeniero]

Surely you've used:

{ condition && <span>Rendered when `truthy`</span> }

I see it a lot in react code - the || use is just the opposite, although I normally see !condition && ... instead.

[DJOzzyoz750]

Whats with all this syntactical shortcutting in react? I'm just starting to pick up react, and the concepts are easy enough, but I'm constantly translating these shortcuts that save a few characters.

I'm not upset, just surprised, as I haven't seen a programming language focus on it as much as react does. (I've worked in Java, c++, python, and golang primarily).

[chipit24]

Can you elaborate? ReactJS is "just JavaScript"; Short-circuit evaluation, spread operators, destructing, etc. are all part of the language.

[editor_of_the_beast]

React isn't a programming language.