Category Archives: React

Three ways to conditionally render components with React and JSX

Sometimes, you want to render a UI component only if a certain condition is true. Perhaps a feature is enabled for a subset of users only (such as administrators or premium accounts), or maybe part of the UI can be toggled on and off in the app’s settings. I’d like to share a few different ways to conditionally render a component with React and JSX that I’ve found useful. Which one you should choose depends on the situation. Sometimes, one approach may be the best tool for the job. Other times, it may come down to personal preference.

Getting started

Let’s consider a basic web app layout. We have a main content section and a sidebar. There’s also a special toolbar that only administrators should be able to see. This toolbar should be hidden from regular users.

For our code examples, we’ll be inside the render() method of the parent component of these three sections. Here’s what it might look like without any conditional rendering:

render()
{
    return (
        <AdminToolbar/>
        <PrimaryContent/>
        <Sidebar/>
    );
}

Let’s assume that this parent component has a prop named isAdmin that we’ll use to figure out if AdminToolbar should render or not.

Now that we’ve established our context, let’s look at our various options for conditional rendering.

Approach 1: A variable and an if() statement

The most basic approach is to store an instance of our AdminToolbar component in a variable, but only if the isAdmin prop is true.

let adminBar = null;
if(this.props.isAdmin)
{
    adminBar = <AdminToolbar/>;
}

Then, we’ll use our ability to embed expressions in JSX to reference the variable inside our JSX.

return (
    { adminBar }
    <PrimaryContent/>
    <Sidebar/>
);

React has no problem dealing with a null value in JSX. If the adminBar variable is null, React will skip over it without rendering anything.

Approach 2: Return null from component’s render() method

In the next example, we leave it up to the AdminToolbar component to decide on its own whether to render or not. Let’s give AdminToolbar its own isAdmin prop so that we can pass our value down one more level:

render()
{
    return (
        <AdminToolbar isAdmin={this.props.isAdmin}/>
        <PrimaryContent/>
        <Sidebar/>
    );
}

Then, in the render() method of the AdminToolbar component, we’ll return null if the prop is false.

class AdminToolbar extends React.Component
{
    render()
    {
        if(!this.props.isAdmin)
        {
            return null;
        }
        return (
            <div>
                { /* omitted for simplicity */ }
            </div>
        );
    }
}

Similar to the previous example, React understands that it shouldn’t render anything when a component returns null from its render() method.

Approach 3: Ternary operator (a ? b : c)

As a final option, we can take advantage of the shorthand nature of the ternary operator to embed everything directly inside our JSX:

render()
{
    return (
        <div>
            { this.props.isAdmin ? <AdminToolbar/> : null }
            <PrimaryContent/>
            <Sidebar/>
        </div>
    );
}

In my opinion, this approach works best when we don’t have any props to pass to the component (or a very small number of props) because we can keep everything on one line. Usually, if we need to pass many props to a component, it’s better to place the props on multiple lines. A ternary operator gets more difficult to read in that situation, and I don’t think it’s particularly obvious how to format this type of complex expression over multiple lines.

This following example seems somewhat reasonable, I guess:

render()
{
    return (
        <div>
            {
                this.props.isAdmin ?
                (
                    <AdminToolbar
                        name="Administrator"
                        needsUpdate={true}/>
                )
                : null
            }
            <PrimaryContent/>
            <Sidebar/>
        </div>
    );
}

However, I don’t think I’d be happy with this formatting if the condition were longer — with multiple parts separated by && and || operators. Similarly, if the final expression were more complex than null, I feel like the mental overhead to understand how each expression fits into the ternary operator would become too high. In my opinion, if the ternary operator needs to be split into multiple lines, our first approach (with the variable and an if() statement) is a much better choice. For one-liners, though, the ternary operator is a pretty compelling option.

One, two, or three?

Which approach do you prefer? Do you know about any other ways to conditionally render a component in React and JSX? If I forgot to include anything, let me know in the comments!

react-loadable and TypeScript error: Property ‘render’ is missing in type ‘{ loader: () => Promise

The react-loadable library provides an excellent way to load React components on demand while displaying a temporary view until they finish loading (such as a spinner animation). Recently, I tried using react-loadable with TypeScript, and the compiler reported a strange and unexpected error. Here’s the journey I took figure out what was wrong, and how I fixed it.

You can see that my code below is very simple, but I was getting an error, for some reason:

import * as React from "react";
import * as Loadable from "react-loadable";
import MyLoadingComponent from "./MyLoadingComponent";

const LoadableMyComponent = Loadable(
{
	loader: () => import("./MyComponent"),
	loading: MyLoadingComponent
});

The full compiler error appears next (with a modified file path to make it more readable):

Argument of type '{ loader: () => Promise<typeof "/path/to/MyComponent">' is not assignable to parameter of type 'Options<any, typeof "/path/to/MyComponent">'.
  Type '{ loader: () => Promise<typeof "/path/to/MyComponent">' is not assignable to type 'OptionsWithRender<any, typeof "/path/to/MyComponent">'.
    Property 'render' is missing in type '{ loader: () => Promise<typeof "/path/to/MyComponent">'.

In my editor, the error begins at the opening curly brace { and ends at the closing curly brace }, so it’s clear that there’s something wrong with the options object that I’m passing in. However, it was not immediately obvious to me why the TypeScript compiler didn’t like my object.

The error says that a render property is missing. My first thought was that I was missing a render() method in a component somewhere. However, both MyComponent and MyLoadingComponent are React components with proper render() methods defined.

The code for MyComponent.tsx appears below:

import * as React from "react";

export default class MyComponent extends React.Component<any>
{
	render()
	{
		return <div>MyComponent has loaded</div>
	}
}

And here’s the code for MyLoadingComponent.tsx:

import * as React from "react";

export default class MyLoadingComponent extends React.Component<any>
{
	render()
	{
		return <div>Loading...</div>;
	}
}

As you can see, render() is not missing in my components. So where exactly should a property named render be defined?

After reading through the react-loadable documentation, I figured out that the options object can be one of a few different variations, and one of them requires a render property. The TypeScript compiler thinks I’m trying to use the variation where this property is required…

…but I’m not.

According to the following comment from the type definitions, I need to meet the following requirements to make the render property optional:

If you do not want to provide a render function, ensure that your function is returning a promise for a React.ComponentType or is the result of import()ing a module that has a component as its `default` export.

You can see that the function that I pass to the loader property should work. I’m loading a module containing MyComponent as the default export, and it extends React.Component.

loader: () => import("./MyComponent")

After some trial and error, I determined the real problem. The React component that I pass to the other option (loading) isn’t accepted because I typed its “props” as any:

class MyLoadingComponent extends React.Component<any>

According to the type definitions for react-loadable, I should use ReactComponent.<Loadable.LoadingComponentProps> instead. I would have expected the TypeScript compiler to figure out that Loadable.LoadingComponentProps can be assigned to any, but I guess not.

Anyway, here’s how I should have defined MyLoadingComponent instead:

import * as React from "react";
import * as Loadable from "react-loadable";

export default class MyLoadingComponent extends React.Component<Loadable.LoadingComponentProps>
{
	render()
	{
		return <div>Loading...</div>;
	}
}

It took me quite some time to figure out what exactly was wrong with my code. The TypeScript compiler was fixated on that render property, which led me down the wrong path. I wish the compiler would have realized that my React.Component was using type any for its props instead of the Loadable.LoadingComponentProps. I wonder if there’s a better way to define these options in the type definitions so that the wrong type for props would have taken precedence over the missing (but not really) render property?