Frontend Beauty
ESC

Type to search the knowledge base.

Avoid Prop Drilling with Composition

Stop threading props through intermediates: children slots, inversion of control, and when context is the right escape hatch.

intermediate3 min read
  • react
  • avoid-prop

Prop drilling is passing data through components that do not use it just so a deep leaf can read it. Five layers of user={user} make refactors brittle and hide what each layer actually needs.

Composition fixes most cases without global state. Context fixes the rest when many distant consumers share stable-ish data.

Docs: Passing Data Deeply with Context, Composition.

Invert control with children

Instead of:

function Page({ user }) {
  return <Layout user={user} />; // Layout only forwards
}
function Layout({ user }) {
  return <Sidebar user={user} />; // Sidebar only forwards
}
function Sidebar({ user }) {
  return <Avatar user={user} />;
}

Compose at the top:

function Page({ user }) {
  return (
    <Layout
      sidebar={<Avatar user={user} />}
      main={<Dashboard />}
    />
  );
}

function Layout({ sidebar, main }) {
  return (
    <div className="layout">
      <aside>{sidebar}</aside>
      <main>{main}</main>
    </div>
  );
}

Layout never sees user. The parent wires the leaf that needs it. Same idea as children patterns.

Provider only where needed

const UserContext = createContext(null);

function App({ user }) {
  return (
    <UserContext.Provider value={user}>
      <Routes />
    </UserContext.Provider>
  );
}

function Avatar() {
  const user = useContext(UserContext);
  return <img src={user.avatarUrl} alt="" />;
}

Do not default to one mega-context for the whole app. Split by update rate (context performance).

When drilling is fine

Two or three layers with props that are part of the intermediate API (onSubmit on a form section) is fine and often clearer than context. Drill until it hurts, then compose, then context.

Depth / fan-out Prefer
1–2 layers Props
Layout chrome children / slots
Many distant readers Context or store
Server data Fetch near consumer / RSC

Interview out-loud

“I reduce prop drilling by composing: parents pass already-configured leaves as children or slot props so intermediates stay dumb. For cross-cutting data read in many places I use context, split by update frequency. I do not reach for Redux just to avoid three prop passes.”

Further reading

Production checklist

  1. Source of truth clear for every piece of UI state?
  2. Remount, route change, and Strict Mode cleanup paths handled?
  3. Urgent updates separated from deferrable work?
  4. Profiled before memo, virtualization, or context splits?
  5. Keyboard, focus, and accessible names still work after the change?

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides