Verified against Claude Code · 2026-07-22
Fix prop drilling without reaching for Redux as the first move
Fixes a prop-drilling chain with composition or a narrowly-scoped context first, and only escalates to an external store if neither actually solves it.
The prompt
Ready to copy — highlighted parts are example details you can swap.
<role> You are fixing a prop-drilling problem in a React component tree. You try composition first, then a narrowly-scoped context, and only recommend an external store if neither one actually solves it. </role> <component_tree> Layout receives user, theme, and onUpdateUser as props and passes all three to Sidebar, which passes all three to Panel, which passes all three to Widget, the only component that actually reads onUpdateUser and theme. </component_tree> <drilled_props> user, theme, onUpdateUser — passed through Layout > Sidebar > Panel > Widget </drilled_props> <fix_order> 1. Check if the intermediate components that just forward the props even need to know about them — if a middle component only passes the drilled props through without reading them, consider passing the already-composed JSX (children or a render prop) down instead, so the data goes directly from the top to where it's actually used and the middle component's own props shrink. 2. If composition doesn't fit because the intermediate components genuinely branch on the data (conditional rendering based on it, not just passing it along), create a context scoped to just this subtree — not a new top-level app-wide context — and provide it at the lowest common ancestor that has the data. 3. Only recommend an external store if the same data is also needed outside this subtree, or if the update frequency makes context problematic per the re-render-on-every-change behavior of context providers. 4. Do not default to "just use Redux/Zustand" — that's an escalation, not a first response. </fix_order> <output_format> 1. Which fix you applied and why the earlier options in the order didn't fit. 2. The updated component tree with the fix applied. 3. The props list for each component, before and after — the point is a visibly shorter list. </output_format>
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Passing already-composed children through the tree is React's own documented alternative to Context for the specific case where intermediate components don't need to read the drilled data, only pass it along — a component that receives finished JSX as a prop doesn't need to know the shape of user or theme at all, which shrinks the middle components' prop lists to nothing rather than just moving the prop names into a context hook. Scoping the fallback context to the subtree that actually needs it, instead of hoisting it to a new top-level provider, keeps the fix proportional and avoids widening the re-render blast radius to the whole app. Making "try composition, then scoped context, then a store" an explicit sequence with a stated rule against defaulting to a store directly targets the most common overreaction in this exact prompt category: reaching for the heaviest tool as the first answer to a problem composition alone would have fixed.
What you get back
Fix applied: composition. Sidebar and Panel never read user, theme, or onUpdateUser — they only forwarded them — so Layout now renders <Sidebar><Panel><Widget user={user} theme={theme} onUpdateUser={onUpdateUser} /></Panel></Sidebar> directly, passing Widget as pre-composed children through Sidebar and Panel. Props before: Sidebar(user, theme, onUpdateUser, children?), Panel(user, theme, onUpdateUser, children?). Props after: Sidebar(children), Panel(children) — both down to a single prop.
Verified against
Claude Code Sonnet 4.6 · 2026-07-22
ChatGPT GPT-5.1 · 2026-07-28
Changelog
- 2026-07-22 — Initial publish, verified against Claude Code (Sonnet 4.6) and ChatGPT (GPT-5.1).
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE

