Editor’s note: This tutorial was last updated in October 2020 to reflect changes introduced in React 16.8 — namely, how to use React Hooks and Fragments for conditional rendering.
JSX is a powerful extension to JavaScript that allows us to define UI components. But it doesn’t support loops or conditional expressions directly (although the addition of conditional expressions has been discussed before).
If you want to iterate over a list to render more than one component or implement some conditional logic, you have to use pure JavaScript. You don’t have a lot of options with looping, either. Most of the time, map
will cover your needs.
But conditional rendering? That’s another story.
What is conditional rendering in React?
In React, conditional rendering refers to the process of delivering elements and components based on certain conditions.
There’s more than one way to use conditional rendering in React. As with most things in programming, some are better suited than others depending on the problem you’re trying to solve.
This tutorial covers the most popular ways to implement conditional rendering in React:
- How to write
if...else
in React - Prevent rendering with
null
- React element variables
- The ternary operator in React
- Short-circuit AND operator (
&&
) - Immediately invoked function expressions (IIFEs)
- React subcomponents
- Enum objects
- Higher-order components (HOCs) in React
We’ll also review some tips and best practices for implementing conditional rendering in React, including:
- Performance considerations
- Conditional rendering with fragments
- Conditional rendering with React Hooks
- Deciding how to implement conditional rendering in React
To demonstrate how all these methods work, we’ll implement a component with a view/edit functionality:
You can try and fork all the examples in JSFiddle.
We’ll start with the most naive implementation using an if...else
block and build it from there.
1. How to write if...else
in React
Create a component with the following state:
class App extends React.Component { constructor(props) { super(props); this.state = {text: '', inputText: '', mode:'view'}; } }
You’ll use one property for the saved text and another for the text that is being edited. A third property will indicate if you are in edit
or view
mode.
Next, add some methods for handling input text and then save and edit events:
class App extends React.Component { constructor(props) { super(props); this.state = {text: '', inputText: '', mode:'view'}; this.handleChange = this.handleChange.bind(this); this.handleSave = this.handleSave.bind(this); this.handleEdit = this.handleEdit.bind(this); } handleChange(e) { this.setState({ inputText: e.target.value }); } handleSave() { this.setState({text: this.state.inputText, mode: 'view'}); } handleEdit() { this.setState({mode: 'edit'}); } }
Now, for the render
method, check the mode
state property to either render an edit button or a text input and a save button, in addition to the saved text:
class App extends React.Component { // … render () { if(this.state.mode === 'view') { return ( <div> <p>Text: {this.state.text}</p> <button onClick={this.handleEdit}> Edit </button> </div> ); } else { return ( <div> <p>Text: {this.state.text}</p> <input onChange={this.handleChange} value={this.state.inputText} /> <button onClick={this.handleSave}> Save </button> </div> ); } }
Here’s the complete Fiddle to try it out:
An if...else
block is the easiest way to solve the problem, but I’m sure you know this is not a good implementation.
It works great for simple use cases, and every programmer knows how it works. But there’s a lot of repetition, and the render
method looks crowded.
So let’s simplify it by extracting all the conditional logic to two render methods: one to render the input box and another to render the button.
class App extends React.Component { // … renderInputField() { if(this.state.mode === 'view') { return <div></div>; } else { return ( <p> <input onChange={this.handleChange} value={this.state.inputText} /> </p> ); } } renderButton() { if(this.state.mode === 'view') { return ( <button onClick={this.handleEdit}> Edit </button> ); } else { return ( <button onClick={this.handleSave}> Save </button> ); } } render () { return ( <div> <p>Text: {this.state.text}</p> {this.renderInputField()} {this.renderButton()} </div> ); } }
Here’s the complete Fiddle to try it out:
If we have more than two branches that depend on the same variable to evaluate the condition, instead of having a big if...else
block:
if(this.state.mode === 'a') { // ... } else if(this.state.mode === 'b') { // ... } else if(this.state.mode === 'c') { // ... } else { // ... }
We can use a switch
statement:
switch(this.state.mode) { case 'a': // ... case 'b': // ... case 'c': // ... default: // equivalent to the last else clause ... }
It may add a bit more clarity, but:
- It’s still too verbose
- It doesn’t work with multiple/different conditions
- Just like an
if...else
statement, you can’t use it inside ofreturn
statement with JSX (except when you use immediately invoked functions, which I’ll cover later)
Let’s look at some additional techniques to improve this code.
Notice that the method renderInputField
returns an empty <div>
element when the app is in view mode. This is not necessary, however.
2. Prevent rendering with null
If you want to hide a component, you can make its render method return null
, so there’s no need to render an empty (and different) element as a placeholder. One important thing to keep in mind when returning null
, however, is that even though the component doesn’t show up, its lifecycle methods are still fired.
Take, for example, the following Fiddle, which implements a counter with two components:
The Number
component only renders the counter for even values; otherwise, null
is returned. When you look at the console, however, you’ll see that componentDidUpdate
is always called regardless of the value returned by render
.
Back to our example, change the renderInputField
method to look like this:
renderInputField() { if(this.state.mode === 'view') { return null; } else { return ( <p> <input onChange={this.handleChange} value={this.state.inputText} /> </p> ); } }
Here’s the complete Fiddle:
One advantage of returning null
instead of an empty element is that you’ll improve the performance of your app a little bit because React won’t have to unmount the component to replace it.
For example, when trying the Fiddle that renders the empty <div>
element, if you open the Inspector tab, you’ll see how the <div>
element under the root is always updated:
Unlike the case when null
is returned to hide the component, where that <div>
element is not updated when the Edit
button is clicked:
Learn more about reconciliation in React, which basically refers to how React updates the DOM elements and how the diffing algorithm works.
Maybe in this simple example, the performance improvement is insignificant, but when working when big components, there can be a difference. I’ll talk more about the performance implications of conditional rendering later. For now, let’s continue to improve this example.
3. React element variables
One thing I don’t like is having more than one return
statement in methods, so I’m going to use a variable to store the JSX elements and only initialize it when the condition is true
:
renderInputField() { let input; if(this.state.mode !== 'view') { input = <p> <input onChange={this.handleChange} value={this.state.inputText} /> </p>; } return input; } renderButton() { let button; if(this.state.mode === 'view') { button = <button onClick={this.handleEdit}> Edit </button>; } else { button = <button onClick={this.handleSave}> Save </button>; } return button; }
This gives the same result as returning null
from those methods. Here’s the Fiddle to try it out:
The main render
method is more readable this way, but maybe it isn’t necessary to use if...else
blocks (or something like a switch
statement) and secondary render methods. Let’s try a simpler approach.
4. The ternary operator in React
Instead of using an if...else
block, we can use the ternary conditional operator:
condition ? expr_if_true : expr_if_false
The operator is wrapped in curly braces, and the expressions can contain JSX, optionally wrapped in parentheses to improve readability. It can also be applied in different parts of the component.
Let’s apply it to the example so you can see this in action. I’m going to remove renderInputField
and renderButton
, and in the render
method, I’m going to add a variable to know if the component is in view
or edit
mode:
render () { const view = this.state.mode === 'view'; return ( <div> </div> ); }
Now you can use the ternary operator to return null
if the view
mode is set, or the input field otherwise:
// ... return ( <div> <p>Text: {this.state.text}</p> { view ? null : ( <p> <input onChange={this.handleChange} value={this.state.inputText} /> </p> ) } </div> );
Using a ternary operator, you can declare one component to render either a save or edit button by changing its handler and label correspondingly:
// ... return ( <div> <p>Text: {this.state.text}</p> { ... } <button onClick={ view ? this.handleEdit : this.handleSave } > {view ? 'Edit' : 'Save'} </button> </div> );
Here’s the Fiddle to try it out:
As mentioned before, this operator can be applied in different parts of the component, even inside return statements and JSX, acting as a one-line if...else
statement. However, exactly for this reason, things can get messy quickly.
Let’s review another technique that can help improve the code.
5. Short-circuit AND operator (&&
)
The ternary operator has a special case where it can be simplified. When you want to render either something or nothing, you can only use the &&
operator. Unlike the &
operator, &&
doesn’t evaluate the right-hand expression if evaluating only the left-hand expression can decide the final result.
For example, if the first expression evaluates to false (false && …
), it’s not necessary to evaluate the next expression because the result will always be false
.
In React, you can have expressions like the following:
return ( <div> { showHeader && <Header /> } </div> );
If showHeader
evaluates to true
, the <Header/>
component will be returned by the expression. If showHeader
evaluates to false
, the <Header/>
component will be ignored, and an empty <div>
will be returned.
This way, the following expression:
{ view ? null : ( <p> <input onChange={this.handleChange} value={this.state.inputText} /> </p> ) }
Can be turned into:
!view && ( <p> <input onChange={this.handleChange} value={this.state.inputText} /> </p> )
Here’s the complete Fiddle:
Looks better, right?
However, the ternary operator doesn’t always look better. Consider a complex, nested set of conditions:
return ( <div> { condition1 ? <Component1 /> : ( condition2 ? <Component2 /> : ( condition3 ? <Component3 /> : <Component 4 /> ) ) } </div> );
This can become a mess pretty quickly. For that reason, sometimes you might want to use other techniques, like immediately invoked functions.
6. Immediately invoked function expressions (IIFEs)
As the name implies, immediately invoked function expressions (IIFEs) are functions that are executed immediately after they are defined — there’s no need to call them explicitly.
Generally, this is how you define and execute (at a later point) a function:
function myFunction() { // ... } myFunction();
But if you want to execute the function immediately after it is defined, you have to wrap the whole declaration in parentheses (to convert it to an expression) and execute it by adding two more parentheses (passing any arguments the function may take).
Either this way:
( function myFunction(/* arguments */) { // ... }(/* arguments */) );
Or this way:
( function myFunction(/* arguments */) { // ... } ) (/* arguments */);
Since the function won’t be called in any other place, you can drop the name:
( function (/* arguments */) { // ... } ) (/* arguments */);
Or you can also use arrow functions:
( (/* arguments */) => { // ... } ) (/* arguments */);
In React, you use curly braces to wrap an IIFE, put all the logic you want inside it (if...else
, switch
, ternary operators, etc.), and return whatever you want to render.
In other words, inside an IIFE, we can use any type of conditional logic. This allows us to use if...else
and switch
statements inside return
statements and JSX if you consider it to improve the readability of the code.
return ( <div> <p>...</p> { (()=> { switch (condition) { case 1: return <Component1 />; case 2: return <Component2 />; default: null; } })() } </div> );
For example, here’s how the logic to render the save/edit button could look with an IIFE:
{ (() => { const handler = view ? this.handleEdit : this.handleSave; const label = view ? 'Edit' : 'Save'; return ( <button onClick={handler}> {label} </button> ); })() }
Here’s the complete Fiddle:
7. React subcomponents
Sometimes, an IFFE might seem like a hacky solution. After all, we’re using React — the recommended approaches are to split up the logic of your app into as many components as possible and to use functional programming instead of imperative programming.
So moving the conditional rendering logic to a subcomponent that renders different things based on its props would be a good option. But here, I’m going to do something a bit different to show you how you can go from an imperative solution to more declarative and functional solutions.
I’m going to start by creating a SaveComponent
:
const SaveComponent = (props) => { return ( <div> <p> <input onChange={props.handleChange} value={props.text} /> </p> <button onClick={props.handleSave}> Save </button> </div> ); };
As properties, it receives everything it needs to work. In the same way, there’s an EditComponent
:
const EditComponent = (props) => { return ( <button onClick={props.handleEdit}> Edit </button> ); };
Now the render
method can look like this:
render () { const view = this.state.mode === 'view'; return ( <div> <p>Text: {this.state.text}</p> { view ? <EditComponent handleEdit={this.handleEdit} /> : ( <SaveComponent handleChange={this.handleChange} handleSave={this.handleSave} text={this.state.inputText} /> ) } </div> ); }
Here’s the complete Fiddle:
If
components
There are libraries like jsx-control-statements that extend JSX to add conditional statements like:
<If condition={ a === 1 }> <span>Hi!</span> </If>
This library is actually a Babel plugin, so the above code is translated to:
{ a === 1 ? <span>Hi!</span> : null; }
Or the Choose
tag, which is used for more complex conditional statements:
<Choose> <When condition={ a === 1 }> <span>One</span> </When> <When condition={ a === 2 }> <span>Two</span> </When> <Otherwise> <span>Default</span> </Otherwise> </Choose>
The above translates to:
{ a === 1 ? ( <span>One</span> ) : a === 2 ? ( <span>Two</span> ) : ( <span>Default</span> ); }
These libraries provide more advanced components, but if we need something like a simple if...else
, we can use a solution similar to Michael J. Ryan’s in the comments for this issue:
const If = (props) => { const condition = props.condition || false; const positive = props.then || null; const negative = props.else || null; return condition ? positive : negative; }; // … render () { const view = this.state.mode === 'view'; const editComponent = <EditComponent handleEdit={this.handleEdit} />; const saveComponent = <SaveComponent handleChange={this.handleChange} handleSave={this.handleSave} text={this.state.inputText} />; return ( <div> <p>Text: {this.state.text}</p> <If condition={ view } then={ editComponent } else={ saveComponent } /> </div> ); }
Here’s the complete Fiddle:
8. Enums objects
Now that the save/edit functionality is encapsulated in two components, we can also use enum objects to render one of them, depending on the state of the application.
An enum is a type that groups constant values. For example, here’s how you define one in TypeScript:
enum State { Save = "Some value", Edit = "Another value" }
JavaScript doesn’t support enums natively, but we can use an object to group all the properties of the enum and freeze that object to avoid accidental changes.
const State = Object.freeze({ Save: "Some value", Edit: "Another value" });
Why not just use constants? Well, the main benefit is that we can use a dynamically generated key to access the property of the object.
const key = condition ? "Save" : "Edit": const state = State[key];
Applying this to our example, we can declare an enum object with the two components for saving and editing:
const Components = Object.freeze({ view: <EditComponent handleEdit={this.handleEdit} />, edit: <SaveComponent handleChange={this.handleChange} handleSave={this.handleSave} text={this.state.inputText} /> });
And use the mode
state variable to indicate which component to show.
const key = this.state.mode; return ( <div> <p>Text: {this.state.text}</p> { Components[key] } </div> );
You can see the complete code in the following fiddle:
JSFiddle
Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle code editor.
https://jsfiddle.net/eh3rrera/7ey56xud/embedded
Enum objects are a great option when you want to use or return a value based on multiple conditions, making them a great replacement for if...else
and switch
statements in many cases.
9. Higher-order components (HOCs) in React
A higher-order component (HOC) is a function that takes an existing component and returns a new one with some added functionality:
const EnhancedComponent = higherOrderComponent(component);
Applied to conditional rendering, a HOC could return a different component than the one passed based on some condition:
function higherOrderComponent(Component) { return function EnhancedComponent(props) { if (condition) { return <AnotherComponent { ...props } />; } return <Component { ...props } />; }; }
There’s an excellent article about HOCs by Robin Wieruch that digs deeper into conditional renderings with higher-order components. For this article, I’m going to borrow the concepts of the EitherComponent
.
In functional programming, the Either
type is commonly used as a wrapper to return two different values. So let’s start by defining a function that takes two arguments, another function that will return a Boolean value (the result of the conditional evaluation), and the component that will be returned if that value is true
:
function withEither(conditionalRenderingFn, EitherComponent) { }
It’s a convention to start the name of the HOC with the word with
. This function will return another function that will take the original component to return a new one:
function withEither(conditionalRenderingFn, EitherComponent) { return function buildNewComponent(Component) { } }
The component (function) returned by this inner function will be the one you’ll use in your app, so it will take an object with all the properties that it will need to work:
function withEither(conditionalRenderingFn, EitherComponent) { return function buildNewComponent(Component) { return function FinalComponent(props) { } } }
The inner functions have access to the outer functions’ parameters, so now, based on the value returned by the function conditionalRenderingFn
, you either return the EitherComponent
or the original Component
:
function withEither(conditionalRenderingFn, EitherComponent) { return function buildNewComponent(Component) { return function FinalComponent(props) { return conditionalRenderingFn(props) ? <EitherComponent { ...props } /> : <Component { ...props } />; } } }
Or, using arrow functions:
const withEither = (conditionalRenderingFn, EitherComponent) => (Component) => (props) => conditionalRenderingFn(props) ? <EitherComponent { ...props } /> : <Component { ...props } />;
This way, using the previously defined SaveComponent
and EditComponent
, you can create a withEditConditionalRendering
HOC and, with this, create an EditSaveWithConditionalRendering
component:
const isViewConditionFn = (props) => props.mode === 'view'; const withEditContionalRendering = withEither(isViewConditionFn, EditComponent); const EditSaveWithConditionalRendering = withEditContionalRendering(SaveComponent);
You can now use it in the render
method, passing all the properties needed:
render () { return ( <div> <p>Text: {this.state.text}</p> <EditSaveWithConditionalRendering mode={this.state.mode} handleEdit={this.handleEdit} handleChange={this.handleChange} handleSave={this.handleSave} text={this.state.inputText} /> </div> ); }
Here’s the complete Fiddle:
Conditional rendering in React: Performance considerations
Conditional rendering can be tricky. As I showed you before, the performance of each option can be different. However, most of the time, the differences don’t matter a lot.
But when they do, you’ll need a good understanding of how React works with the virtual DOM and a few tricks to optimizing performance. Here’s a good article about optimizing conditional rendering in React — I totally recommend you read it.
The essential idea is that changing the position of the components due to conditional rendering can cause a reflow that will unmount/mount the components of the app. Based on the example of the article, I created two JSFiddles.
The first one uses an if...else
block to show/hide the SubHeader
component:
The second one uses the short circuit operator (&&
) to do the same:
Open the Inspector and click on the button a few times. You’ll see how the Content
component is treated differently by each implementation.
Here’s how the if...else
block treats the component:
And here’s how the short-circuit operator do it:
Conditional rendering with fragments
How do you render multiple child components depending on a certain condition? The answer is by using fragments.
Fragments allow you to return multiple elements by grouping them without adding an extra node to the document object model (DOM).
You can use fragments with their traditional syntax:
return ( <React.Fragment> <Button /> <Button /> <Button /> </React.Fragment> );
Or with their short syntax:
return ( <> <Button /> <Button /> <Button /> </> );
That said, when it comes to rendering multiple elements with fragments depending on a condition, you can use any of the techniques described in this article.
For example, you could use the ternary operator this way:
{ view ? null : ( <React.Fragment> <Button /> <Button /> <Button /> </React.Fragment> ) }
Better yet, you could use a short-circuit &&
:
{ condition && <React.Fragment> <Button /> <Button /> <Button /> </React.Fragment> }
You could also encapsulate the rendering of the child elements in a method and use an if
or switch
statement to decide what to return:
render() { return <div>{ this.renderChildren() }</div>; } renderChildren() { if (this.state.children.length === 0) { return <p>Nothing to show</p>; } else { return ( <React.Fragment> {this.state.children.map(child => ( <p>{child}</p> ))} </React.Fragment> ); } }
Conditional rendering with React Hooks
Today, most experienced React developers use Hooks to write components. So instead of having a class like this:
import React, { Component } from 'react'; class Doubler extends Component { constructor(props) { super(props); this.state = { num: 1, }; } render() { return ( <div> <p>{this.state.num}</p> <button onClick={() => this.setState({ num: this.state.num * 2 }) }> Double </button> </div> ); } }
You can use the useState
hook to write the component with a function:
import React from 'react'; function Doubler() { const [num, setNum] = React.useState(1); return ( <div> <p>{num}</p> <button onClick={() => setNum(num * 2)}> Double </button> </div> ); }
Just like fragments, you can use any of the techniques described in this article to conditionally render a component that uses Hooks.
function Doubler() { const [num, setNum] = React.useState(1); const showButton = num <= 8; const button = <button onClick={() => setNum(num * 2)}>Double</button>; return ( <div> <p>{num}</p> {showButton && button} </div> ); }
The only caveat is that you can’t conditionally call a Hook so it’s not always executed. According to the Hooks documentation:
Don’t call Hooks inside loops, conditions, or nested functions. Instead, always use Hooks at the top level of your React function. By following this rule, you ensure that Hooks are called in the same order each time a component renders. That’s what allows React to correctly preserve the state of Hooks between multiple
useState
anduseEffect
calls.
This usually happens with the useEffect
hook. You can’t put a condition that could prevent the hook from being called every time the component is rendered, like this:
if (shouldExecute) { useEffect(() => { // ... } }
You have to put the condition inside the Hook:
useEffect(() => { if (shouldExecute) { // ... } }, [shouldExecute])
What’s the best way to implement conditional rendering in React?
As with many things in programming, there are many ways to implement conditional rendering in React. I’d say that, with exception of the first method (if...else
with many returns), you’re free to choose whatever method you want.
You can decide which one is best for your situation based on:
- Your programming style
- How complex the conditional logic is
- How comfortable you are with JavaScript, JSX, and advanced React concepts (like HOCs)
And, all things being equal, always favor simplicity and readability.
Ensure components render in production
Debugging React applications can be difficult, especially when there is complex state. If you’re interested in monitoring and tracking Redux state for all of your users in production, try LogRocket.
LogRocket is like a DVR for web apps, recording literally everything that happens on your site. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred.
The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.
Modernize how you debug your React apps — start monitoring for free.
Very very good article !
Nice article!
Why do you still use class components? It’s 2020, function components with hooks are not an “alternative” way. They are THE way to go and classes are unnecessary for the examples you show.
Your article is a great resource for beginner React developers, but also confusing, because you use class components.
This post was originally published several years ago, before the stable release of the Hooks API, and we just updated it a few months back. We’ve added an editor’s note to clarify. Thanks for keeping us honest.
Althought this article has inmense value and all of this is valid React, when an application gets big, using live vanilla javascript to condition the render adds complexity and you start building an enviroment very prone to errors later, good practice will be create a component that handles the condition taking it as a prop and returns the children or null, and reuse it across the app, making your render entirely declarative instead of imperative… has been an old trade in San Francisco since the begining of React.. truth is you can call it how ever you want,, but make sure the component do that.. back in the pre-hooks days ppl use to do it using a HOC ….