React Conditional Rendering and Lists

A comprehensive guide to react conditional rendering and lists with production examples and best practices.

Why Conditional Rendering and Lists Are Core to React

In React, conditional rendering and lists are not just features—they are the backbone of dynamic UIs. Every production app uses them to show or hide elements based on state, and to render collections of data. Without a solid grasp of these patterns, you'll end up with bloated components, unnecessary re-renders, and hard-to-debug bugs. This section sets the stage by explaining why these concepts matter in real-world applications, from dashboards to e-commerce product lists. We'll focus on the mental model: think of your UI as a function of state, where conditionals and loops are just JavaScript expressions inside JSX. The key is to keep them simple and predictable. Avoid complex ternaries or nested conditions that obscure logic. Instead, extract conditions into helper functions or early returns. For lists, always use a stable key and avoid index keys unless the list is static and small. This foundation will save you from performance pitfalls and maintainability nightmares.

function UserGreeting({ user }) {
  if (!user) {
    return <p>Please sign in.</p>;
  }
  return <p>Welcome back, {user.name}!</p>;
}

function ItemList({ items }) {
  if (items.length === 0) {
    return <p>No items found.</p>;
  }
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

Conditional Rendering Patterns: If, Ternary, &&, and Switch

React offers several ways to conditionally render elements. The most common are if statements (outside JSX), ternary operators, logical AND (&&), and switch statements. Each has its place. Use if statements for complex logic or early returns. Use ternaries for simple binary choices inside JSX. Use && for rendering something only when a condition is true—but beware of falsy values like 0 or empty string, which can render unexpected output. Switch statements are rare but useful when you have multiple discrete states. In production, the choice matters for readability and bug prevention. For example, using && with a count of 0 will render '0' instead of nothing. Always coerce to boolean: {!!count && <Component />}. Also, avoid deeply nested ternaries; extract into a variable or a function. This section will show you each pattern with realistic examples and warn you about common pitfalls.

function StatusMessage({ status }) {
  // Ternary
  return (
    <div>
      {status === 'loading' ? <Spinner /> : <Content />}
    </div>
  );
}

function Notification({ count }) {
  // Logical AND - careful with falsy values
  return (
    <div>
      {count > 0 && <span>{count} new messages</span>}
    </div>
  );
}

function UserRole({ role }) {
  // Switch-like using object map
  const roleComponents = {
    admin: <AdminPanel />,
    user: <UserDashboard />,
    guest: <GuestView />,
  };
  return roleComponents[role] || <DefaultView />;
}

Rendering Lists with map() and Keys

The map() function is the standard way to render lists in React. It transforms an array into an array of React elements. The critical part is the key prop. Keys help React identify which items have changed, been added, or removed. Using index as a key is a common anti-pattern that leads to bugs when the list is reordered or filtered. In production, always use a unique identifier from your data, like an ID. If your data doesn't have one, generate a stable key using a library like uuid or nanoid. Never use Math.random() as keys—they change every render, causing unnecessary re-renders and potential state loss. This section will also cover rendering nested lists and handling empty states. Remember: keys only need to be unique among siblings, not globally. We'll also discuss the importance of keeping list items as pure components to avoid performance issues.

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id}>
          <span>{todo.text}</span>
          <button onClick={() => handleDelete(todo.id)}>Delete</button>
        </li>
      ))}
    </ul>
  );
}

// Bad: index as key
{todos.map((todo, index) => <li key={index}>{todo.text}</li>)}

Conditional Rendering with Lists: Filtering and Sorting

Often you need to conditionally render a list based on filters or sort order. This combines conditional logic with list rendering. The cleanest approach is to compute the filtered/sorted list before the JSX, using useMemo to avoid recalculating on every render. For example, a search input filters a list of products. You compute the filtered list with useMemo, then map over it. This keeps your JSX clean and your logic testable. Avoid chaining filter and map inside JSX—it's harder to read and debug. Also, consider debouncing the filter input to avoid performance hits on large datasets. In production, always handle edge cases: empty results, loading state, and error state. This section will walk through a realistic search-and-filter component with proper memoization and error boundaries.

function ProductList({ products, searchTerm }) {
  const filteredProducts = useMemo(() => {
    if (!searchTerm) return products;
    return products.filter(p =>
      p.name.toLowerCase().includes(searchTerm.toLowerCase())
    );
  }, [products, searchTerm]);

  return (
    <ul>
      {filteredProducts.length === 0 ? (
        <li>No products found.</li>
      ) : (
        filteredProducts.map(product => (
          <li key={product.id}>{product.name}</li>
        ))
      )}
    </ul>
  );
}

Handling Complex Conditional UI: Multiple States and Error Boundaries

Real apps have multiple states: loading, empty, error, and success. Conditional rendering must handle all of them gracefully. A common pattern is to use a state machine or a reducer to manage these states. For example, a data-fetching component might have states: 'idle', 'loading', 'success', 'error'. You can render different UI for each state using a switch or object map. Additionally, error boundaries can catch rendering errors in child components and display fallback UI. This is especially important for list items that might throw errors due to malformed data. In production, never assume data is well-formed. Always validate and handle errors. This section will show you how to build a robust component that handles all states and uses error boundaries to prevent the entire app from crashing.

function DataFetcher({ url }) {
  const [state, setState] = useState('idle');
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    setState('loading');
    fetch(url)
      .then(res => res.json())
      .then(data => {
        setData(data);
        setState('success');
      })
      .catch(err => {
        setError(err);
        setState('error');
      });
  }, [url]);

  if (state === 'loading') return <Spinner />;
  if (state === 'error') return <ErrorFallback error={error} />;
  if (state === 'success') return <List data={data} />;
  return null;
}

class ListErrorBoundary extends React.Component {
  state = { hasError: false };
  static getDerivedStateFromError() { return { hasError: true }; }
  render() {
    if (this.state.hasError) return <p>Something went wrong.</p>;
    return this.props.children;
  }
}

Performance Optimization: Virtualization and Memoization

Rendering large lists (thousands of items) can cause performance issues. Virtualization libraries like react-window or react-virtuoso render only the visible items, drastically reducing DOM nodes. For conditional rendering, avoid unnecessary re-renders by using React.memo on list items and useCallback on event handlers. Also, avoid creating new objects or functions in the render cycle. For example, inline arrow functions in list items cause re-renders because they are new references each time. Use useCallback to stabilize them. In production, we've seen apps become unusable with 10k items without virtualization. This section will show you how to implement a virtualized list with react-window and optimize conditional rendering within items.

import { FixedSizeList } from 'react-window';

const Row = React.memo(({ index, style, data }) => {
  const item = data[index];
  return (
    <div style={style}>
      {item.condition ? <span>Active</span> : <span>Inactive</span>}
    </div>
  );
});

function LargeList({ items }) {
  return (
    <FixedSizeList
      height={400}
      itemCount={items.length}
      itemSize={35}
      itemData={items}
    >
      {Row}
    </FixedSizeList>
  );
}

Common Anti-Patterns and How to Fix Them

Even experienced developers fall into traps with conditional rendering and lists. Common anti-patterns include: using index as key, mutating state directly (e.g., push instead of spread), rendering arrays of components without keys, using && with numbers, deeply nested ternaries, and mixing logic in JSX. Each of these leads to bugs or performance issues. For example, mutating state with push causes React to miss updates because the reference doesn't change. Always use immutable updates. Another anti-pattern is rendering a list inside a conditional without handling the empty state. This section will list the top 5 anti-patterns with before/after code, explaining why they're bad and how to fix them. Production code should be clean, predictable, and easy to debug.

// Bad: mutating state
const addItem = () => {
  items.push(newItem); // mutates original array
  setItems(items); // React may not re-render
};

// Good: immutable update
const addItem = () => {
  setItems(prev => [...prev, newItem]);
};

// Bad: nested ternary in JSX
{condition ? (a ? <A /> : <B />) : <C />}

// Good: extract into variable
let content;
if (condition) {
  content = a ? <A /> : <B />;
} else {
  content = <C />;
}
return <div>{content}</div>;

Testing Conditional Rendering and Lists

Testing is crucial for production code. For conditional rendering, test each state (loading, empty, error, success) using React Testing Library. For lists, test that the correct number of items render, that keys are unique, and that interactions (like delete) work. Use data-testid or role queries to select elements. Avoid testing implementation details like state values; instead, test what the user sees. For example, assert that a loading spinner appears when the component is in loading state. Also, test edge cases: empty list, single item, and large lists. This section will provide a testing strategy with examples using Jest and React Testing Library. We'll also cover snapshot testing for list components, but caution against overusing it.

import { render, screen, fireEvent } from '@testing-library/react';
import TodoList from './TodoList';

test('renders empty state', () => {
  render(<TodoList todos={[]} />);
  expect(screen.getByText('No items found.')).toBeInTheDocument();
});

test('renders list items', () => {
  const todos = [{ id: 1, text: 'Learn React' }];
  render(<TodoList todos={todos} />);
  expect(screen.getByText('Learn React')).toBeInTheDocument();
});

test('calls onDelete when delete button clicked', () => {
  const handleDelete = jest.fn();
  const todos = [{ id: 1, text: 'Test' }];
  render(<TodoList todos={todos} onDelete={handleDelete} />);
  fireEvent.click(screen.getByText('Delete'));
  expect(handleDelete).toHaveBeenCalledWith(1);
});

Real-World Patterns: Compound Components and Render Props

For complex conditional rendering, consider advanced patterns like compound components or render props. Compound components (e.g., <Tabs> with <Tab> and <TabPanel>) allow you to manage state internally while giving the consumer control over rendering. Render props let you pass a function as a child to control what gets rendered. These patterns are useful for building reusable UI libraries. For lists, consider using a generic List component that accepts a renderItem prop. This avoids duplicating list logic. In production, these patterns improve code reuse and separation of concerns. However, they can add complexity. Use them when you have multiple components sharing the same logic. This section will show a simple Tabs component using compound components and a List component with render props.

function List({ items, renderItem }) {
  return (
    <ul>
      {items.map((item, index) => (
        <li key={item.id}>
          {renderItem(item, index)}
        </li>
      ))}
    </ul>
  );
}

// Usage
<List
  items={products}
  renderItem={(product) => (
    <div>
      <h3>{product.name}</h3>
      <p>{product.price}</p>
    </div>
  )}
/>

Conditional Rendering and Lists with TypeScript

TypeScript adds type safety to conditional rendering and lists. Define proper types for props and state to catch errors at compile time. For conditional rendering, use discriminated unions to model different states. For lists, ensure the key is typed correctly and that the data array is typed. Use generics for reusable list components. This section will show how to type a state machine with a discriminated union, and how to create a typed List component. In production, TypeScript prevents many runtime errors, especially when dealing with API responses that may have missing fields. Always use strict mode and avoid any. This will make your conditional rendering and list logic more robust.

type State<T> =
  | { status: 'loading' }
  | { status: 'error'; error: Error }
  | { status: 'success'; data: T[] };

function DataList<T extends { id: string }>({ state, renderItem }: {
  state: State<T>;
  renderItem: (item: T) => React.ReactNode;
}) {
  if (state.status === 'loading') return <Spinner />;
  if (state.status === 'error') return <p>{state.error.message}</p>;
  return (
    <ul>
      {state.data.map(item => (
        <li key={item.id}>{renderItem(item)}</li>
      ))}
    </ul>
  );
}

Server-Side Rendering Considerations

When using SSR (Next.js, Remix), conditional rendering and lists behave differently. On the server, you don't have browser APIs like window or localStorage. Conditional rendering based on those will cause hydration mismatches. Use useEffect for client-only logic. For lists, ensure keys are stable across server and client to avoid hydration errors. Also, avoid rendering large lists on the server that could bloat the HTML payload. Consider lazy loading or client-side fetching for large datasets. This section will cover common SSR pitfalls and how to handle them, including using dynamic imports with ssr: false and using useEffect for client-side conditions. In production, hydration mismatches can break the entire page, so test thoroughly.

function ClientOnlyList() {
  const [data, setData] = useState([]);
  useEffect(() => {
    fetch('/api/data')
      .then(res => res.json())
      .then(setData);
  }, []);
  // Render nothing on server, then hydrate on client
  if (typeof window === 'undefined') return null;
  return (
    <ul>
      {data.map(item => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
}

Conclusion: Build Production-Ready Conditional Rendering and Lists

Conditional rendering and lists are fundamental to React. By mastering these patterns—using early returns, stable keys, memoization, virtualization, and proper testing—you can build performant and maintainable UIs. Remember to handle all states, avoid anti-patterns, and leverage TypeScript for safety. In production, the difference between a good app and a great one often comes down to these details. Always think about edge cases: empty lists, loading states, errors, and large datasets. Use the patterns discussed here as a checklist for your next component. TheCodeForge.io encourages you to write code that is not just functional but production-ready from day one.

// Checklist for production-ready conditional rendering and lists
// 1. Handle all states: loading, empty, error, success
// 2. Use stable keys (not index)
// 3. Memoize derived data with useMemo
// 4. Virtualize large lists
// 5. Test each state and interaction
// 6. Use TypeScript for type safety
// 7. Avoid hydration mismatches in SSR

null vs undefined: When to Return Nothing

In React, returning null from a component means "render nothing," while returning undefined causes a runtime error in class components (though function components handle it gracefully by rendering nothing). The semantic difference matters: null explicitly signals an intentional empty state, whereas undefined often indicates a missing return statement. For reconciliation, React treats null as a signal to skip rendering and unmount any existing children, while undefined may lead to unexpected behavior in older React versions. Best practice: always return null for conditional rendering. Example: if (!items.length) return null; ensures the component renders nothing when the list is empty. Avoid returning undefined by ensuring all code paths have a return statement. In TypeScript, the return type should be JSX.Element | null to enforce this.

function ItemList({ items }) {
  if (!items.length) {
    return null; // Explicitly render nothing
  }
  return (
    <ul>
      {items.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
}

// Bad: returning undefined
function BadList({ items }) {
  if (!items.length) {
    return; // returns undefined, may cause issues
  }
  return <ul>...</ul>;
}

Form Conditional Patterns

Forms often require conditional logic, such as disabling the submit button when the form is invalid. Use state to track form validity and conditionally set the disabled attribute. Example: const [isValid, setIsValid] = useState(false); then <button disabled={!isValid}>Submit</button>. Update validity on input changes using validation functions. For complex forms, consider using a library like Formik or React Hook Form, but the core pattern remains: derive disabled state from validation state. Another pattern: show/hide form sections based on user selections (e.g., shipping address fields only if "different billing address" is checked). Use conditional rendering with && or ternary for these sections.

function SignupForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const isValid = email.includes('@') && password.length >= 6;

  return (
    <form>
      <input value={email} onChange={e => setEmail(e.target.value)} />
      <input type="password" value={password} onChange={e => setPassword(e.target.value)} />
      <button disabled={!isValid}>Submit</button>
    </form>
  );
}

Complex Conditions: The Variable Assignment Pattern

When you have three or more mutually exclusive branches, using ternary operators or && chains becomes messy. The variable assignment pattern assigns JSX to a variable using let and conditionally sets it. Example: let content; if (status === 'loading') content = <Spinner />; else if (status === 'error') content = <Error />; else content = <Data />; return <div>{content}</div>;. This pattern is more readable and maintainable for complex logic. It also allows early returns for simple cases. For even more branches, consider using a lookup object or switch statement inside the component.

function Dashboard({ status }) {
  let content;
  if (status === 'loading') {
    content = <Spinner />;
  } else if (status === 'error') {
    content = <Error message="Failed to load" />;
  } else if (status === 'empty') {
    content = <EmptyState />;
  } else {
    content = <DataTable />;
  }
  return <div>{content}</div>;
}