Redžep Murati for Team ORNIO

Posted on Jul 8, 2021

Simplify condition rendering in React.js

#react #javascript #webdev #showdev

As a professional developer you are forced to stay up to date with the latest trends in technology. This year I've added Svelte to my bucket list as a new framework to learn.
While researching Svelte I was surprised by the way they handle condition rendering.
Take a look at this example found in their docs:

    {#if user.loggedIn}
      <button on:click={toggle}>
        Log out
      </button>
    {/if}

Everything is neatly wrapped with if clause and separated from normal flow.

After a quick prototyping I present to you the most powerful component I have ever written, an IF component.

   const IF = ({ condition, children }) => {
     if (!condition) return null;
     return <>{children}</>;
   };

By offloading condition into a separate component this will improve code cleanness and readability by quite a margin (for free).

Let’s imagine the Svelte example in our React app. It would go something like this:

…
return (
    <>
      {user.loggedIn && <button>Log out</button>}
    </>
  );
...

This is not an end of the world issue when you have just one condition but as our apps grow, so do the conditions.

Take a look at the same component now refactored to use IF:

…
return (
    <IF condition={user.loggedIn}>
      <button>Log out</button>
    </IF>
  );
...

Now it’s easier to track down conditions and debug faulty ones, plus the code looks way cleaner now that conditions are gone from JSX.

Hope you found this helpful ❤️

Top comments (38)

chris-czopp • Jul 8 '21

Nice one! If you're interested in exploring other frameworks, in SolidJS you have:

function Show<T>(props: {
  when: T | undefined | null | false;
  fallback?: JSX.Element;
  children: JSX.Element | ((item: T) => JSX.Element);
}): () => JSX.Element;

...which you can use like:

<Show when={state.count > 0} fallback={<div>Loading...</div>}>
  <div>My Content</div>
</Show>

I find really neat.

Chetan Atrawalkar • Jul 8 '21

How to write this type of code(like second) in Dev Community post please help

chris-czopp • Jul 8 '21

Do you mean syntax highlighting? If so, then like this:

It's just Mardown compatible with Github.

Chetan Atrawalkar • Jul 8 '21

Yes but how please share image details

Redžep Murati • Jul 8 '21

Take a look at this official markdown guide:
markdownguide.org/extended-syntax/

Edgar Mendoza • Jul 11 '21 • Edited

@chetan_atrawalkar just surround your code with the following:

console.log("Hello World");

Chetan Atrawalkar • Jul 11 '21

Thank you❤️

nemit74180 • Jul 13 '21

Redžep Murati • Jul 8 '21

Nice tip. Thank you ❤️

Mike Talbot ⭐ • Jul 8 '21 • Edited

Nice, I do something similar - it's also cool to add then and else as props. I also do this with switch:

import React, { useContext, useState } from "react"

const SwitchContext = React.createContext()

function ensureArray(ar) {
    return Array.isArray(ar) ? ar:[ar].filter((f) => f!==undefined)
}

function noop() {}

export function Switch({ value, children }) {
    const [switchContext] = useState({ cases: {} })
    switchContext.value = value
    return <SwitchContext.Provider value={switchContext}>{children}</SwitchContext.Provider>
}


export function Case({ when, children, execute = noop }) {
    const toCheck = ensureArray(when)
    const { value, cases } = useContext(SwitchContext)
    let condition = toCheck.some((when) => {
        if (typeof when === "function") {
            return when(value)
        } else {
            return when === value
        }
    })

    cases["" + when] = condition
    if (condition) {
        execute()
        return <>{children}</>
    } else {
        return null
    }
}

export function CaseElse({ children }) {
    const { cases } = useContext(SwitchContext)
    if (!Object.values(cases).some((v) => !!v)) {
        return <>{children}</>
    }
    return null
}

I use it like this:

 <Switch value={column.type}>
            <Case when="action">
                <TableCell className={classes.tight} onClick={prevent(noop)}>
                    <LoadedAction column={column} item={item} />
                </TableCell>
            </Case>
            <Case when={["more", "than", "one", "reason", ()=>column.name === "including this!"]}>
                   {/* Some other cell */}
            </Case>
            {/* Other cases */}
            <CaseElse>
                <TableCell className={classes.tight}>
                    <LoadedColumn column={column} item={item} />
                </TableCell>
            </CaseElse>
</Switch>

Lonli-Lokli • Jul 27 '21

I've tried it, it's pretty neat but do you know how to limit type with React context? Ie to make Typescript do not complain about missing props

stackblitz.com/edit/react-ts-6ynx8...

Mike Talbot ⭐ • Jul 27 '21

I tried the link but didn't see any lint issues etc, what is it complaining about?

Lonli-Lokli • Jul 10 '21

Nice, but you are missing Default case when no other matches

Mike Talbot ⭐ • Jul 11 '21 • Edited

Nope, I just called it CaseElse (my project has a ton of things called DefaultXYZ so it doesn't scan well).

Redžep Murati • Jul 9 '21

Oh wow this looks interesting. Thank you for sharing :)

Baron Willeford • Jul 8 '21

Your approach has an issue: the children are still being rendered, they’re just not being displayed. So if you have a component that, say, makes a network request when it mounts, that’s still going to happen, which is likely not what you want.

Florian Rappl • Jul 9 '21

This is wrong. It's true that the elements are still constructed, but nothing is mounted and since React only goes in top-bottom the non-rendering / non-mounted children will never be looked at.

Look at this example.

   const IF = ({ condition, children }) => {
     if (!condition) return null;
     return <React.Fragment>{children}</React.Fragment>;
   };

   const Example = ({name}) => {
    console.log('Render Example', name);
    return <div />;
   };

ReactDOM.render(<div><IF condition={false}><Example name="false - not displayed" /></IF><IF condition={true}><Example name="true - displayed" /></IF></div>, document.querySelector("#app"))

What you'll see in the console is:

"Render Example", "true - displayed"

(Note there is no false - displayed shown.)

So there shouldn't be any such thing as a network request (which anyway shouldn't appear there, because these things are side-effects and, e.g., useEffect would only be called on mounted components anyway).

The only issue with this approach is that you construct more objects (i.e., React elements) than you would otherwise. This becomes only an issue when you have a larger render tree spawning from there.

Redžep Murati • Jul 9 '21

Exactly 🙂 Thank you for detailed clarification.

Joe Pea • Jul 10 '21

No issue with extra elements in Solid, no matter how big the app gets. Check it out!

solidjs.com

Heath Daniel • Jul 8 '21

Interesting. Can you explain further? They are rendered by the parent component but the 'IF' component just controls whether they are displayed or not?

Baron Willeford • Jul 8 '21

Correct. ‘IF’ and the child are rendered from the same place. The ‘children’ prop is just a reference, is not actual call site. To actually prevent it from being rendered, you would want to call the conditionally rendered component from the ‘IF’.

Heath Daniel • Jul 8 '21

I'm not sure if this is a good way to test but I tried testing it by creating a component that logs to the console when it renders and it looks like that code never ran.

Link to CodePen: codepen.io/hedwardd/pen/xxdOpxy?ed...

Could it have something to do with it being a functional component?

Leiv Fredrik Berge • Jul 8 '21

Exactly, this will actually add the child node to the tree and perform any effects for example. You can avoid this by using render props, but that kinda defeats the purpose.

Heath Daniel • Jul 8 '21

Does it? Now I'm confused. If you look at the CodePen I created, the effects don't seem to run (unless I'm misunderstanding something)

Redžep Murati • Jul 9 '21

Actually it shouldn't run. I've created a codesadbox for you guys to check out where you can see both functional and class based components.
Here is the link:
codesandbox.io/s/nice-wiles-cwfi6?...

Christos Litras • Jul 10 '21 • Edited

IMO there is no need to create an <IF> component. For most simple cases, ternary operator <condition> ? <if-true> : <if-false> or simple boolean operators && and/or || will do the job; for something more complex, it would be better to create an additional function to render it. If we want to render it directly in place and we have many conditions/components to check, there is a new Javascript do expression (tc39/proposal-do-expressions) that is in stage 1 of the TC39 process and it will solve such problems by using some native syntax like:

const Component = props => (
  <div className="myComponent">
    {do {
      if (color === "blue") {
        <BlueComponent />;
      } else if (color === "red") {
        <RedComponent />;
      } else if (color === "green") {
        <GreenComponent />;
      }
      <DefaultColorComponent />;
    }}
  </div>
);

We can already use it by using Babel plugin @babel/plugin-proposal-do-expressions.

jfullerco • Jul 10 '21

Figured I’d share one of the first use cases I found for this and it’s one I believe could be helpful to others. That’s in hydrating state with React Router useHistory state in the event of a browser refresh.

import React from ‘react’
const CheckIfCacheNeeded = ({
   value, 
   setValue, 
   fallbackValue, 
   handleRestore, 
   children }) => {
   value != undefined ? value : 
   handleRestore(fallbackValue, setValue)
 return(
   {children}
  )
}
export default CheckIfCacheNeeded

When calling the component you’d need to add a handleRestore function that took the fallbackValue and setter function as parameters.

It works well with React Router useHistory state that persists during browser refresh.

jfullerco • Jul 8 '21

This is a question, not a critique, is it not necessary to check for the existence of the conditional variable if you use the NOT operator?

Fwiw, great post! Definitely will use this as inspiration for some component refactoring on my current project.

Thanks!!

Redžep Murati • Jul 9 '21

Hello, no actually you don't have to every falsy value is considered as false.

jfullerco • Jul 9 '21

Thanks! That’s super helpful to know!

Cody Seibert • Jul 11 '21

To each their own, but I argue this is a unnecessary abstraction. It’s like creating an add() function that adds numbers when you can do a + b in code.