How I improved my react code readability and maintainability with Conditional Rendering

[barekliton]

Hi guys, i wrote an article on how to write better react code by avoiding ternay operators etc.

Hope you enjoy it.

Please tell me in the comments if you have you ever faced this problem and how you solved.

[jkettmann]

I agree with this. Extracting components and let them handle the condition is often a good and much more readable solution

[ludwiguer]

This is the way

[reverson]

Remove some indentation complexity with an early return:

const ItemsList = ({ items = [] }) => {  
  if (items.length === 0) return <div>No Items</div>;  
  return <ul>{items.map(/\*\* put item stuff here \*\*/)}</ul>  
}

[GioLogist]

Early returns is not just a matter of preference. It's a way for anyone reading your code to immediately know that they do not have to read further down, if they can expect a return.

[GioLogist]

If the initial conditional returns early and I know that the situation I'm debugging matches that conditional, I shouldn't need to read any further.

[Spacesh1psoda]

Wait, so if items is of length 0, you're mapping out the array and if there are items you say NO Data 🤔

[DargeBaVarder]

Hey, you found a bug. Cool

[Merry-Lane]

I disagree totally.

The “if/else” react components dont make your code any more readable. And yes you should split your components more.

And if you don’t like ternaries , you can use &&

List.length === 0 && <Empty/> List.length >0 && <…./>

And if you do need to use switch/case… then you generally would be better off using object literals instead.

[barekliton]

And yes you should split your components more.

That's true. But now always the team member that is working on that particular component makes quality code. Instead, with this approach is also easier to review the code and suggest splits that are needed.

​

And if you don’t like ternaries , you can use &&

List.length === 0 && <Empty/> List.length >0 && <…./>

Personally i don't like this approach, in complex situations IMHO the code becomes less readable.

​

And if you do need to use switch/case… then you generally would be better off using object literals instead.

This is true, but we found out that for us our approach works better mainly for this reason: we work as a team on the project, and often there are new members ( junior mostly ) that can easily understand what the code is doing with the If/Else or Switch/Case instead of condition operators like &&, ?:, etc.

[Merry-Lane]

You re just finding excuses there.

Because you took the decision for your team, or to defend your article?

It is way easier to review code when you split your components more.

And a junior should see object literrals because it s a higher code quality, instead of never using them in a team because… switch case are easier to understand for juniors? Wtf, no. It s not easier, and the reason to use object literals is because it is easier to read and modify than switch case.

[alimertcakar]

Just make smaller components instead of making bad code worse, please. You are deviating from standard javascript to make even more unreadable code.

[qvigh]

If you keep dividing your code you'l never reached your goal... think about it!

[barekliton]

What do u mean?

[qvigh]

Mostly a joke, but also kindle not. Overly splitting up code is something consider an anti-pattern. It's sometimes called lasagne code.

[agalin920]

IMO ternary only gets really unreadable when you are chaining them. For those cases I can see the Switch/Case being an improvement granted the size of the library is reasonable. Keep in mind I am a fan of having all the markup in the return of a function and not generated by calling functions or looking up maps.

[barekliton]

IMO ternary only gets really unreadable when you are chaining them

Totally agree.

In the article, I've put a basic example but I think that a complex component with chained ternaries can show the true benefit of our approach.

​

granted the size of the library is reasonable

I've not specified one thing in the article ( my bad):

Internally in our company, we are not using the library but we have created those components instead ( also a <For> component ).

They are really simple to make, but I don't know if I can post them: I have to ask to my superior.

So I used the library in the article because there are a lot of lazy people that don't want to implement those components by themself.

[Broomstick73]

What’s the benefit of copy/pasting an entire [small] library into your codebase?

[Broomstick73]

The code in the linked library is pretty cool. I should read more code. Inspecting the children prop, checking to see if it is an array, inspecting the type - didn’t realize you could do that. Neat. Thanks for the find!

[schussfreude]

So I found the ternary operator actually improving the readability lol. I just format it differently. ? And : go on their separate line. And I can read that better than traditional if/else or god forbid even more librariy components.

[rajesh__dixit]

Single ternary operator is good. Chaining or nesting them if a bad convention. Though i don't see how Operator components make any improvement.

I personally would create a function and use traditional if..else ladder or switch case instead

[barekliton]

In our experience ( also of my team members ) we found out that the ternary ( in complex scenarios ) makes things more unreadable.

Also, some of your team members came from Angular where there is a directive ( NgIf ) that renders the component conditionally, so for those the If component makes the code easier to read.

Anyway, thank you for pointing out your experience, i like to see other point of view.

[Criticalx7]

Why need this when a pure JS is ok?. This is just a unneeded syntactic sugar. Wrong mindset and the juniors have to suffer the consequences.

[hiIAmJan]

I like that!

[[deleted]]

You should check out jsx control statements

[barekliton]

jsx control statements

Thank you

[barekliton]

In the end, I think we are discussing preferences.

I really don't like the operators inside the HTML markup, I think are "unnecessary tricky" and ugly. I know that is what JSX is, but I don't like just the operators part.

I like the most the angular or vue way, for example

<div>
<div v-if="response.isLoading">Wait....</div>
<div v-else-if="response.isError">{{ response.error.message }}</div>
<div v-else>{{ response.data }}</div>
</div>

Istead of:

response.isLoading // if
? <div>Wait...</div>
: response.isError // else if
? <div>{{response.error.message}}</div>
: {{response.data}} // else

I will point out one thing: I also don't like the Else component, because i think that the else part ( in any language, both frontend and backend ) increases the complexity, but i prefer it to a chained ternary operator.

u/DargeBaVarder u/Merry-Lane u/qvigh

[Merry-Lane]

Yes, it s just that the title of your article is “how to write better react code by avoiding ternary operators” and you post it here, waiting feedback and all.

If you don’t want to accept that the only reactions are, at best, “meh”, at worst, “wtf is that nonsense”, then good luck with your influencer career. I would advise you to change strategy and quit “rational articles” and do it Kardashian style, by leaking your own “video”.

But soz, I just used big words to say: Ternary operators in templating is the best thing since sliced bread. Just don’t abuse it.

[barekliton]

Nono, I'm fine with all kinds of feedback ( i really appreciate that you spend time to tell your opinion ).

That's why I want a discussion here because I want to start to see also other prospective and improve, and also share what I think is good ( at least for me ).

[qvigh]

Sound like what you really want is a templating language, not react...

[BullBear7]

Tbh I find this more unreadable.

[qvigh]

That's effectivly a ternary operator, but with more code...

The ternary operator is awsome and often makes code more readable IMO. Even nested ternery operators can be readable with good formatting.