🔀 Conditional Rendering Patterns

Why Conditional Rendering?

Your UI is a function of state. When state says "still loading," you show a spinner; when it says "here's the data," you show the list; when it says "something broke," you show an error. Because JSX is just JavaScript expressions, you steer it with the same tools you already know: &&, the ternary ? :, if statements, and variables.

The trick is knowing which of the four patterns fits. A one-sided "show this only if" wants &&. A two-sided "this or that" wants a ternary. A whole component that branches into several full-screen states wants early returns. And a chunk of markup you want to compute before the return wants an element variable. Let's take them one at a time.

Pattern 1: The && Operator

Use condition && <element> when you want to render something only when a condition is true, and render nothing otherwise. It works because of how JavaScript's && evaluates: if the left side is truthy, the expression becomes the right side; if the left side is falsy, the expression becomes the left side (which React ignores when it is false, null, or undefined).

function Inbox({ unreadCount, isAdmin }) {
    return (
        <header>
            <h1>Inbox</h1>

            {/* Renders the badge only when there are unread messages */}
            {unreadCount > 0 && (
                <span className="badge">{unreadCount} new</span>
            )}

            {/* Renders the admin link only for admins */}
            {isAdmin && <a href="/admin">Admin</a>}
        </header>
    );
}

// ❌ When items.length is 0, this puts a stray "0" on screen.
{items.length && <ItemList items={items} />}

// ✅ Force a real boolean on the left side.
{items.length > 0 && <ItemList items={items} />}

// ✅ Or coerce with a double-bang.
{!!items.length && <ItemList items={items} />}

You can stack several independent && lines for a component that layers optional pieces:

function Profile({ user, isLoading, error }) {
    return (
        <div>
            {isLoading && <Spinner />}
            {error && <ErrorBanner message={error} />}
            {user && !isLoading && !error && (
                <section>
                    <h2>{user.name}</h2>
                    <p>{user.bio}</p>
                </section>
            )}
        </div>
    );
}

That last block hints at a smell: when you find yourself writing user && !isLoading && !error, the states are really mutually exclusive, and early returns (Pattern 3) will read far better.

Pattern 2: The Ternary

Use condition ? <a> : <b> when you must choose between two alternatives — an either/or. Unlike &&, the ternary always renders one branch or the other, so it is the tool for "this or that," including toggling a className.

function ConnectionStatus({ isOnline }) {
    return (
        <span className={isOnline ? 'status online' : 'status offline'}>
            {isOnline ? 'Online' : 'Offline'}
        </span>
    );
}

function AuthButton({ user, onLogin, onLogout }) {
    return user
        ? <button onClick={onLogout}>Log out</button>
        : <button onClick={onLogin}>Log in</button>;
}

Ternaries shine for small inline choices. They become unreadable when nested. This works but nobody enjoys maintaining it:

// ❌ Nested ternaries — hard to read, easy to break.
function Dashboard({ user }) {
    return (
        <div>
            {user ? (
                user.isAdmin ? <AdminPanel /> : <UserPanel />
            ) : (
                <GuestPanel />
            )}
        </div>
    );
}

function Dashboard({ user }) {
    if (!user) return <GuestPanel />;
    if (user.isAdmin) return <AdminPanel />;
    return <UserPanel />;
}

Pattern 3: Early Returns

When a whole component swaps between several distinct, full states, put if statements before the main return and return early for each special case. Each guard handles one case and exits, so by the time execution reaches the bottom you are on the guaranteed "happy path." This is the cleanest pattern for the loading/error/empty/content quartet you will write constantly.

import { useState, useEffect } from 'react';

function OrdersView() {
    const [orders, setOrders] = useState([]);
    const [loading, setLoading] = useState(true);
    const [error, setError]     = useState(null);

    useEffect(() => {
        fetchOrders()
            .then(setOrders)
            .catch((err) => setError(err.message))
            .finally(() => setLoading(false));
    }, []);

    // Each guard peels off one state and returns.
    if (loading) return <Spinner label="Loading orders…" />;
    if (error)   return <ErrorBanner message={error} />;
    if (orders.length === 0) return <EmptyState label="No orders yet" />;

    // Happy path: we know orders is a non-empty array.
    return (
        <ul>
            {orders.map((order) => (
                <li key={order.id}>{order.summary}</li>
            ))}
        </ul>
    );
}

Pattern 4: Element Variables

Sometimes you want to compute a piece of markup with ordinary if logic, then drop it into a larger layout that is shared across all cases. Assign the JSX to a variable before the return, then reference {variable} inside the markup. This keeps the surrounding structure (a header, a footer, a wrapper) written once, with only the middle varying.

function MessagePanel({ status, data }) {
    // Build the body with plain if/else — no JSX gymnastics.
    let body;
    if (status === 'loading') {
        body = <Spinner />;
    } else if (status === 'error') {
        body = <p role="alert">Something went wrong.</p>;
    } else {
        body = <DataTable rows={data} />;
    }

    // The wrapper is written once; only `body` changes.
    return (
        <section className="panel">
            <h2>Activity</h2>
            {body}
            <footer>Last updated just now</footer>
        </section>
    );
}

A close cousin is the object-map (lookup) pattern, which replaces a long switch with a plain object keyed by the state value:

function StatusIcon({ status }) {
    const icons = {
        success: <CheckIcon />,
        warning: <WarnIcon />,
        error:   <ErrorIcon />,
    };
    // Fall back to a default for any unknown status.
    return icons[status] ?? <InfoIcon />;
}

Rendering Nothing

A component is allowed to render nothing: return null and React renders an empty result (no DOM). This is how a component politely opts out.

function WarningBanner({ show, children }) {
    if (!show) return null; // render nothing at all
    return <div className="warning">{children}</div>;
}

Choosing a Pattern

A quick decision guide you can keep in your head:

These are not rigid rules — they are the readable default for each shape of problem. The guiding principle is the same one you have met all week: keep the branching logic obvious, and keep JSX shallow.

Practice & Quiz

function CartBadge({ items }) {
    return (
        <div className="cart">
            🛒
            {items.length && <span className="count">{items.length}</span>}
        </div>
    );
}

function CartBadge({ items }) {
    return (
        <div className="cart">
            🛒
            {items.length > 0 && (
                <span className="count">{items.length}</span>
            )}
        </div>
    );
}

function UserList({ loading, error, users }) {
    if (loading) return <p>Loading…</p>;
    if (error)   return <p role="alert">Error: {error}</p>;
    if (users.length === 0) return <p>No users found.</p>;

    return (
        <ul>
            {users.map((u) => (
                <li key={u.id}>{u.name}</li>
            ))}
        </ul>
    );
}

Best Practices & Pitfalls

✅ Do

• Use && for one-sided show/hide, ternary for a single either/or
• Prefer early returns for mutually exclusive full-component states
• Put a comparison (> 0) on the left of && when the value could be 0
• Extract complex branching into a helper function, element variable, or object map
• Call all Hooks before any early return

❌ Don't

• Nest ternaries more than one level deep
• Put a bare number on the left of && in JSX
• Return undefined when you mean "render nothing" — return null
• Place a return above a useState/useEffect call

// Unmounts when hidden — loses internal state each time.
{show && <Panel />}

// Stays mounted, just visually hidden — keeps state, costs memory.
<div style={{ display: show ? 'block' : 'none' }}>
    <Panel />
</div>

Summary

📚 Additional Resources

• react.dev — Conditional Rendering
• react.dev — The logical AND operator and the 0 pitfall
• MDN — Conditional (ternary) operator

🚀 What's Next?

You can now render the right amount of UI (lists) and the right UI for the state (conditionals). Next you'll learn how React encourages you to build UI: Composition vs inheritance — why React apps combine small components with children and props instead of extending classes, and how that keeps your component tree flexible.