Prop Drilling in React: What It Is and How to Avoid It

Prop drilling is passing a prop through components that do not use it, only so a component further down the tree can. Here user travels from App through Page and Sidebar to reach Avatar, the one component that reads it.

import { useState } from 'react';

function Avatar({ user }) {
    return <strong>{user.name}</strong>;
}

function Sidebar({ user }) {
    console.log('Sidebar got user, but only passes it on');
    return (
        <aside style={{ padding: 8, background: '#f3f3f3' }}>
            Signed in as <Avatar user={user} />
        </aside>
    );
}

function Page({ user }) {
    console.log('Page got user, but only passes it on');
    return (
        <main>
            <h3>Dashboard</h3>
            <Sidebar user={user} />
        </main>
    );
}

export default function App() {
    const [user, setUser] = useState({ name: 'Ada' });
    return (
        <div>
            <button onClick={() => setUser({ name: user.name === 'Ada' ? 'Linus' : 'Ada' })}>
                Switch user
            </button>
            <Page user={user} />
        </div>
    );
}

Four levels, and only the last one cares about user. The Console shows Page and Sidebar running for a value they never display. Click the button and they log again.

Why it hurts

Two or three levels is fine. Prop drilling becomes a problem as the tree grows:

• The middle components carry props they do not use. Page and Sidebar now have a user prop in their signature, so you cannot read them without wondering what it is for.
• Every change touches every layer. Add user.avatarUrl or a second value like onLogout, and you edit each component on the path, not just the two ends.
• Moving a component breaks the chain. Move Avatar into a different branch and you must thread user through a new path.
• It is easy to drop a prop. Forget to forward it in one layer and the deep component gets undefined, with no error at the layer that lost it.

Try it: add an onLogout function in App that Avatar should call. You will edit all four components.

Fix 1: composition with children

This fix is the one people skip. Instead of passing data down so a deep component can render with it, let the component that owns the data render the deep component itself, and pass the finished element down as children (or any other prop). The middle layers render a slot and never see user.

import { useState } from 'react';

function Avatar({ user }) {
    return <strong>{user.name}</strong>;
}

function Sidebar({ children }) {
    console.log('Sidebar rendered');
    return <aside style={{ padding: 8, background: '#f3f3f3' }}>{children}</aside>;
}

function Page({ sidebar }) {
    console.log('Page rendered');
    return (
        <main>
            <h3>Dashboard</h3>
            {sidebar}
        </main>
    );
}

export default function App() {
    const [user, setUser] = useState({ name: 'Ada' });
    return (
        <div>
            <button onClick={() => setUser({ name: user.name === 'Ada' ? 'Linus' : 'Ada' })}>
                Switch user
            </button>
            <Page
                sidebar={
                    <Sidebar>
                        Signed in as <Avatar user={user} />
                    </Sidebar>
                }
            />
        </div>
    );
}

Page and Sidebar no longer know a user exists. App creates Avatar where user lives and hands it down as a ready element. Layout components like these become reusable, and adding onLogout is now a change in App and Avatar only. Both still log on every click, because App passes them a new element each time it renders: composition simplifies the code, not the number of renders. The children page covers more slot patterns.

Composition works when the component that owns the data can also decide what the deep part looks like. It does not help when the deep component sits inside a library or a structure the owner does not render.

Fix 2: context

When many components at different depths need the same value (the theme, the signed-in user, the current language), put it in context. Any component under the provider reads it with useContext, and nothing in between changes.

import { createContext, useContext, useState } from 'react';

const UserContext = createContext(null);

function Avatar() {
    const user = useContext(UserContext);
    return <strong>{user.name}</strong>;
}

function Greeting() {
    const user = useContext(UserContext);
    return <p>Welcome back, {user.name}.</p>;
}

function Sidebar() {
    return (
        <aside style={{ padding: 8, background: '#f3f3f3' }}>
            Signed in as <Avatar />
        </aside>
    );
}

function Page() {
    return (
        <main>
            <Greeting />
            <Sidebar />
        </main>
    );
}

export default function App() {
    const [user, setUser] = useState({ name: 'Ada' });
    return (
        <UserContext value={user}>
            <button onClick={() => setUser({ name: user.name === 'Ada' ? 'Linus' : 'Ada' })}>
                Switch user
            </button>
            <Page />
        </UserContext>
    );
}

Avatar and Greeting read the user from two different depths, and Page and Sidebar take no props. Add a third reader anywhere under Page and it works without touching the rest. The cost: the data flow is no longer visible in the props, and every reader renders when the value changes. The useContext page covers providers, defaults and those re-renders.

Fix 3: a state library

For large app state that many components read and that changes often (a cart, a document editor, live data), a state library such as Redux Toolkit, Zustand or Jotai lets each component subscribe to just the slice it uses. That avoids both drilling and the "every consumer renders" cost of one big context. It is also another dependency and another set of concepts, so reach for it when the first two fixes stop being enough, not to fix a prop that travels three levels.

// Zustand, for comparison (not available in the editor here)
const useCart = create((set) => ({
    items: [],
    add: (item) => set((s) => ({ items: [...s.items, item] })),
}));

function CartCount() {
    const count = useCart((s) => s.items.length); // renders only when the count changes
    return <span>{count}</span>;
}

When prop drilling is fine

Passing props is how React data flows, and it is the easiest pattern to read: you can follow a value from the top to the bottom by looking at the JSX. A prop that goes through one or two components that use part of it, or through a short chain of closely related components, is not a problem to solve. Lift state to the closest common parent, pass it down, and only change approach when the middle layers start carrying props they have no use for.