DEV Community

Cover image for Conditionally render react components in cleaner way
Yogini Bende
Yogini Bende

Posted on • Updated on

Conditionally render react components in cleaner way

Hello folks,

Almost in every app, we encounter situations where we need to render components or elements conditionally. If a user is logged in, the show user her profile else ask her to login, if the user is admin, show him admin pages etc. are just a few scenarios out of them. The most common practice for such use cases is use of if-else, ternary operators, && operators or switch cases.

Though these are simple to use options, at times, they may make your code messier. Today let’s cover two ways which are very effective and cleaner in terms of handling situations like this.

Using Enum

Let’s consider a scenario, where you want to display a settings page of your app based on the user role. The conditions here are,

  • If the user is admin, show her admin settings page.
  • If the user is not admin, show user settings page.
  • If the user is a guest, ask her to login to get her role.

Simple enough! Apart from this, let's also print the username on their respective pages. (This is just to understand how we can pass props to the components). I have created two different components, AdminSettings and UserSettings with some list items to replicate the real world component.

Both the component are as below -

const AdminSettings = ({ username }) => {
    return (
        <>
            <p>Hello {username}</p>
            <ul>
                <li>Admin Settings Option 1</li>
                <li>Admin Settings Option 2</li>
                <li>Admin Settings Option 3</li>
            </ul>
        </>
    );
};


const UserSettings = ({ username }) => {
    return (
        <>
            <p>Hello {username}</p>
            <ul>
                <li>User Settings Option 1</li>
                <li>User Settings Option 2</li>
                <li>User Settings Option 3</li>
            </ul>
        </>
    );
};
Enter fullscreen mode Exit fullscreen mode

Now let’s understand the conditional rendering. We will have one outer settings component, which will get both username and userRole. Using these two options we can decide which setting component to render. This outer settings component will have all the logic of this conditional rendering. Let’s first see the settings component and then understand the enum and conditional rendering.

const Settings = (props) => {
    const { userRole, username } = props;

    const roleSettings = (username) => ({
        admin: <AdminSettings username={username} />,
        user: <UserSettings username={username} />,
        guest: <p>Hello, you will need to login first!!</p>,
    });

    return (
        <div>
            <h1>Settings</h1>
            <p>{roleSettings(username)[userRole]}</p>
        </div>
    );
};

export default Settings;
Enter fullscreen mode Exit fullscreen mode

In the above code, the roleSettings function is considered as enum. Basically, it is just returning an object with different components. Hence in the return statement, we are actually trying to render one key of that object which matches the userRole. As that key contains the component, our required component will get rendered correctly.

As roleSettings is a function, the whole conditional rendering becomes very clean and easy to implement. Also, you don't need to hardcode many values in your application. You can pass props down to the components using the same function.

Apart from enum, other effective way is using HOC (Higher Order Component).

Using HOC

Higher Order Components in React are the wrapper components which takes the component as an argument and returns a component. Higher order components are considered very effective when working on role based access control systems. Though that is out of scope for this article, I will surely try to cover it in some of my next articles.

For now, just to give you a small example of HOC used for conditional rendering, lets consider the same use-case and use a HOC to show logged-in user.

The HOC will look like this -

function withLogin(Component) {
  return function EnhancedComponent({ isLoggedIn, ...props }) {
    if (isLoggedIn) {
      return <Component {...props} />;
    }

    return (
      <div>
        <p>Hello, please login to see your profile!</p>
      </div>
    );
  };
}

const ShowProfile = withLogin(Profile);

function App({ profile, isLoggedIn }) {
  return (
    <div>
      <h1>Hello Conditional Rendering</h1>

      <ShowProfile isLoggedIn={isLoggedIn} profile={profile} />
    </div>
  );
}
Enter fullscreen mode Exit fullscreen mode

If you check the code, withLogin is a Higher Order Component, which will return detailed profile or settings page, if the user is logged in, else it will just return a message asking user to login.

We can use similar HOC for loaders or more complex permission based use-cases, which we will be covering in our next article.

If you are using more effective ways of conditional rendering or some different use-cases for HOCs, do share them with me in comments!

You can also connect with me on Twitter or buy me a coffee if you like my articles.

Keep learning!

Top comments (33)

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
 
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
 
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
 
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
 
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
 
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
 
lxxmi3 profile image
Teabag

Great Post! Saved it for future implementations :D

Collapse
 
hey_yogini profile image
Yogini Bende

Thank you 🙌

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
 
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

Some comments may only be visible to logged-in visitors. Sign in to view all comments.