🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.
🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.
REFERENCEreact

react Documentation

LOADING ENGINE...

Conditional Component Rendering

AI & DATA SCIENCE // conditional-component-rendering

Conditional component rendering means choosing which entire component to render based on a condition, such as switching between a loading, error, or success view, rather than conditionally rendering a small piece of markup.

Syntax

{status === 'loading' ? <Spinner /> : status === 'error' ? <ErrorMessage /> : <Content />}

Deep Dive Course

While the same ternary, &&, and if/else techniques used for conditionally rendering small pieces of markup apply equally to swapping entire components, this pattern deserves its own attention once there are more than two possible states to represent, like loading/error/success, or several different role-based views of the same page — at that point, an if/else chain, a switch statement mapping each state to its component, or even a lookup object keyed by state name, generally reads far more clearly than a chain of nested ternaries or &&s crammed into the JSX.

1Understanding Conditional Component Rendering

While the same ternary, &&, and if/else techniques used for conditionally rendering small pieces of markup apply equally to swapping entire components, this pattern deserves its own attention once there are more than two possible states to represent, like loading/error/success, or several different role-based views of the same page — at that point, an if/else chain, a switch statement mapping each state to its component, or even a lookup object keyed by state name, generally reads far more clearly than a chain of nested ternaries or &&s crammed into the JSX.

💡

Once you're choosing between three or more entire components based on some state value, a switch statement or a plain lookup object mapping each state to its component is almost always more readable than a chain of nested ternaries.

editor.html
function Page({ status }) {
  if (status === 'loading') return <Spinner />;
  if (status === 'error') return <ErrorMessage />;
  return <Content />;
}
localhost:3000

2Practical Example

Here is a real-world application of Conditional Component Rendering showing how it is used in production React code.

editor.html
const views = {
  loading: Spinner,
  error: ErrorMessage,
  success: Content
};

function Page({ status }) {
  const View = views[status] ?? Content;
  return <View />;
}
localhost:3000

3Best Practices

Follow these guidelines when working with Conditional Component Rendering:

1. Use a switch statement, or a plain object mapping state values to components, once there are three or more entire components to choose between, rather than a chain of nested ternaries

2. Keep each conditionally-rendered branch as its own separate, named component, so the top-level conditional logic reads clearly as a simple dispatch rather than mixing layout details into the condition itself

3. Compute which component to render into a variable before the return statement for anything beyond the simplest single ternary, keeping the actual JSX return statement clean and readable

⚠️

Tip: Once you're choosing between three or more entire components based on some state value, a switch statement or a plain lookup object mapping each state to its component is almost always more readable than a chain of nested ternaries.

editor.html
function Page({ status }) {
  if (status === 'loading') return <Spinner />;
  if (status === 'error') return <ErrorMessage />;
  return <Content />;
}
localhost:3000

Examples

Example 01Basic Usage
function Page({ status }) {
  if (status === 'loading') return <Spinner />;
  if (status === 'error') return <ErrorMessage />;
  return <Content />;
}
Example 02Advanced Example
const views = {
  loading: Spinner,
  error: ErrorMessage,
  success: Content
};

function Page({ status }) {
  const View = views[status] ?? Content;
  return <View />;
}

Best Practices

  • Use a switch statement, or a plain object mapping state values to components, once there are three or more entire components to choose between, rather than a chain of nested ternaries
  • Keep each conditionally-rendered branch as its own separate, named component, so the top-level conditional logic reads clearly as a simple dispatch rather than mixing layout details into the condition itself
  • Compute which component to render into a variable before the return statement for anything beyond the simplest single ternary, keeping the actual JSX return statement clean and readable

Interview Question

Why does a lookup object mapping state values to components tend to scale better than a chain of nested ternaries once there are several possible components to choose between?

Hint: Think about how each approach changes as more possible states/components need to be added over time.

A chain of nested ternaries, condition1 ? A : condition2 ? B : condition3 ? C : D, grows both visually and cognitively more tangled with each additional case added, since every new condition nests one level deeper inside the previous one, making the overall structure progressively harder to read and to correctly modify without introducing a mistake in the nesting. A lookup object instead represents the entire mapping as a flat, simple data structure, each state value paired with its corresponding component with no nesting at all, and adding a new case just means adding one new flat key-value pair to that object, without touching or restructuring anything else. This flat structure is also easier to scan at a glance, to test independently of any component rendering, and to potentially extend or modify at runtime, which is exactly why it tends to remain clear and maintainable even as the number of possible states/components grows well beyond what a chain of nested ternaries can comfortably handle.

Exercises

MediumPractice using Conditional Component Rendering in a real scenario.
View Solution
function Page({ status }) {
  if (status === 'loading') return <Spinner />;
  if (status === 'error') return <ErrorMessage />;
  return <Content />;
}

Frequently Asked Questions

Why does a lookup object mapping state values to components tend to scale better than a chain of nested ternaries once there are several possible components to choose between?

A chain of nested ternaries, condition1 ? A : condition2 ? B : condition3 ? C : D, grows both visually and cognitively more tangled with each additional case added, since every new condition nests one level deeper inside the previous one, making the overall structure progressively harder to read and to correctly modify without introducing a mistake in the nesting. A lookup object instead represents the entire mapping as a flat, simple data structure, each state value paired with its corresponding component with no nesting at all, and adding a new case just means adding one new flat key-value pair to that object, without touching or restructuring anything else. This flat structure is also easier to scan at a glance, to test independently of any component rendering, and to potentially extend or modify at runtime, which is exactly why it tends to remain clear and maintainable even as the number of possible states/components grows well beyond what a chain of nested ternaries can comfortably handle.

Related Functions

ternary-operatorconditional-rendering-with-if-elselazy-loading