DEV Community

Cover image for Conditionally render react components in cleaner way

Conditionally render react components in cleaner way

Yogini Bende on February 23, 2021

Hello folks, Almost in every app, we encounter situations where we need to render components or elements conditionally. If a user is logged in, t...
Read full post
Collapse
 
wintercounter profile image
Victor Vincent • • Edited

For me HOCs in general are an anti-pattern, you can always find better solutions using hooks and context.

In this particular case showing the right component should be the role of your routing. For example using react-router you can simply do:

if (!loggedIn) {
    rerurn (
         <Redirect to={{
              path: '/login',
              state: { message: 'You need to login to see your settings` }
         }} />
     )
}
Enter fullscreen mode Exit fullscreen mode

Another anti-pattern is creating renderItem and such render functions. React components already functions itself. If you stick to it, you can have a much cleaner code base at the end.

The problem was also stated previously that in your examples all components will get constructed at load time for no reason. It was also stated this can be solved just by assigning the component itself to the property values instead the components with JSX definition, but that sacrifices dynamic usage, maintainability and edge case handling. This is why IMO switch-case is a superior solution.

To stick to your use case, I'd simply do the following:

const Settings = () => {
    const { role } = useContext(SessionContext)

    switch (role) {
        case 'admin': return <AdminSettings />
        case 'user': return <UserSettings />
        default: return <LoggedOut>Login to see your profile</LoggedOut>
    }
}
Enter fullscreen mode Exit fullscreen mode
  • Follows a component-only pattern. No {renderSettings(role)}/{settingsComponents[role]}, but <Settings />
  • No HoC magic.
  • It doesn't bring up performances concerns.
  • More readable.
  • Better maintainability by supporting any other cases/props.
Collapse
 
sultan99 profile image
Sultan • • Edited

HOC is not an anti-pattern - it is HOF if we consider any component as a function, but hooks break the main FP rule - the function purity and I consider it as a side-effect. I agree with you, the best solution for this example are routers and HOC should be used for something else.

I prefer to create some helper functions which can be used across the project:

export const select = (...list) => value => list.reduce(
  (acc, next) => acc || next(value), null
)

export const when = (test, wanted) => value => (
  test === value && wanted
)
Enter fullscreen mode Exit fullscreen mode

and use them:

const DefaultSettings = () => (
  <p>What the Hell Are You?</p>
)

const selectSettings = select(
  when(`admin`, AdminSettings),
  when(`user`, UserSettings),
  when(`guest`, GuestSettings),
  () =>  DefaultSettings
)

const UserSettings = ({ userRole, username }) => {
  const Settings = selectSettings(userRole)
  return (
    <div>
      <h1>Settings</h1>
      <Settings username={username}/>
    </div>
  )
}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
mikef profile image
Mike Feltman •

"For me HOCs in general are an anti-pattern, you can always find better solutions using hooks and context."

Nailed it!

Collapse
 
estevanjantsk profile image
Estevan Jantsk •

Exactly!

Collapse
 
jwp profile image
John Peters •

Clever...

{roleSettings(username)[userRole]}
Enter fullscreen mode Exit fullscreen mode

Thanks!

Collapse
 
skyjur profile image
Ski • • Edited

Clever is not a compliment in code and this example is not one that anyone should follow. Simple not clever is what we want.

Collapse
 
jwp profile image
John Peters •

You mean function compositional patterns are ugly? I just stated it was clever because it took me a while to understand it.

Thread Thread
 
danielo515 profile image
Daniel Rodríguez Rivero •

This is not about function composition, it is that you need to parse and execute the code in your head to understand what the outcome will be. Exactly the opposite as what declarative means.

Thread Thread
 
jwp profile image
John Peters •

Be nice, I just got out of 3rd grade last year. My point is both functional composition and what was shown are similar with the confusion factor. The only difference is there is plenty of raving going out about the beauty of functional composition.

Thread Thread
 
danielo515 profile image
Daniel Rodríguez Rivero •

I don't know where do you get that my answer was not nice, but I assure you I was not pretending to be aggressive.
I am a big fan of functional composition, but years and experience taught me that the code I want to debug is the simplest possible one. So I only use functional composition when it really improves simplicity or doesn't hurt maintainability. In this article, none of those are met.

Collapse
 
wintercounter profile image
Victor Vincent •

Default is not my concern at all, it can be replaced with case 'guest'. My problem is using an enum:

  • with component definitions (foo: <Bar />): it has performance costs
  • with direct component values (foo: Bar): it sacrifices flexibility and maintainability.

The last example you wrote is also an anti-pattern I explained.

As a hint, this code snippet alone here should be a red flag in the 90% of the cases: <Component {...props} />. By seeing the code you don't know what your component exactly is, and what props it is getting. This could be the equivalent of TS's any in React.

Collapse
 
dungmidside profile image
Dung Tran •

A downside of enum solution is all the component will be compiled even it doesn't need to rendered

Collapse
 
hey_yogini profile image
Yogini Bende •

We can use enums more creatively and achieve performance as well. Luke have shown a really good example for that below.

Collapse
 
ridays2001 profile image
Riday •

So, we have to compromise on performance to get clean code?

Collapse
 
hey_yogini profile image
Yogini Bende •

Not really. Check what Luke have shared!

Thread Thread
 
ridays2001 profile image
Riday •

Hmm... Makes sense... Nice article!

 
wintercounter profile image
Victor Vincent •

That it needs an extra tool (TS) to make it somewhat useable imo already validates my concern. You still cannot SEE from the code what it is.

Why is it so obvious that all components will receive the same prop always? Even in the example there is the logged out case which makes this invalid. Sure, it works fine until I need more/different props, but why would I settle down with a solution that doesn't let me modify later? Especially when the other solution doesn't cost me any extra effort over the enum one.

Collapse
 
evolify profile image
evolify • • Edited

How about this ?

const visible = true
return(
    <div>
        <div r-if = {visible}>content</div>
    </div>
)
Enter fullscreen mode Exit fullscreen mode

see babel-plugin-react-directive

Collapse
 
ridoansaleh profile image
Ridoan •

This remains me the Vue.js code

Collapse
 
evolify profile image
evolify •

If it is easy to use, why not?

Collapse
 
georgesofianosgr profile image
George Sofianos • • Edited

I've used HOCs before, but nowadays I'm trying to avoid them. I'm trying to keep my code small, simple, readable. This would be my solution.

const Settings = ({role, username}) => (
  {role === "admin" && <AdminSettings username={username} /> }
  {role === "user" && <UserSettings username={username} /> }
  {!role && <p>Hello, you will need to login first!!</p> }
)

const App = ({user}) => (
  <Settings role={user?.role} username={user?.username} />
)
Enter fullscreen mode Exit fullscreen mode
Collapse
 
krishan111 profile image
Krishan111 •

There are many small things in this post about which I even do not care and error comes XD, thanks for posting

Collapse
 
hey_yogini profile image
Yogini Bende •

I hope this have helped you in some way!

Collapse
 
jennawagnercode profile image
Jenna Wagner •

Yes that happens several time with me too

Collapse
 
thomasburleson profile image
Thomas Burleson • • Edited

Enums are very powerful and restrict the keys that can be used.
For clarity, the roleSettings function returns a hashmap (key/value pairs). It is not an enum.

Thx for sharing two cool approaches to conditional renderings.
To validate the userRole and provide a fallback to guest, I recommend this:

Collapse
 
hey_yogini profile image
Yogini Bende •

Yeah. That's a good way to optimise when you are dealing with large components! We can modify the enum solutions more creatively to achieve both performance as well as simplicity of code.

Collapse
 
jackmellis profile image
Jack •

For many conditional rendering cases I really like jsx-control-statements (specifically If and Choose)
npmjs.com/package/babel-plugin-jsx...

Collapse
 
ben profile image
Ben Halpern •

Great post

Collapse
 
lxxmi3 profile image
Teabag •

Great Post! Saved it for future implementations :D

Collapse
 
hey_yogini profile image
Yogini Bende •

Thank you 🙌

Collapse
 
jordanaf808 profile image
jordanaf808 •

Wow, even the comments section has great information! Thanks everyone!

Collapse
 
moezkouni profile image
MoezKouni •

The best way is to use switch case statement to avoid constructing the other components. Otherwise, good article. Thanks

Collapse
 
kapekost profile image
Kostas Kapetanakis •

Really great points!
A nice addition would be to add in the mix the Lazy loading, this way a user with role A won’t even have a link to receive bundles that won’t be meant for them ;)