Fix prop drilling without reaching for Redux as the first move

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 the real problem in front of you.

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.

DRILLED PROPS
user, theme, onUpdateUser — passed through Layout, Sidebar, Panel, down to Widget.

NEEDED OUTSIDE THIS SUBTREE
No — user and theme are read elsewhere in the app, but through a separate top-level AuthContext already; this drilling is purely internal to the Layout subtree.

UPDATE FREQUENCY
theme changes a handful of times per session at most; user rarely changes at all during a session.

FIX ORDER
Check first whether the intermediate components that just forward the props even need to know about them at all — if a middle component only passes the drilled props through without reading any of them, consider passing the already-composed JSX down instead, as children or a render prop, so the data goes directly from the top to where it is actually used and the middle component's own prop list shrinks to nearly nothing. If composition does not fit because the intermediate components genuinely branch on the data — real conditional rendering based on it, not just passing it along untouched — 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 actually has the data. Only recommend an external store if the same data is also needed outside this subtree per the cross-subtree requirement above, or if the update frequency makes context genuinely problematic because every consumer of a context re-renders on every value change regardless of which part of that value it reads. Do not default to "just use Redux" or "just use Zustand" as a first response — that is a deliberate escalation with a real cost in added dependency and indirection, applied only once the first two options have been checked and ruled out for a stated reason. When a scoped context ends up being the right fit, wrap its useContext call in a small custom hook that throws a clear error if used outside the provider, rather than having every consuming component call the raw useContext(SomeContext) directly and silently receive undefined if the provider is missing somewhere up the tree. Do not fix prop drilling by bundling several unrelated props into one options or config object passed down instead — that changes the drilling's shape without reducing it, and it actively hides which individual pieces of data each intermediate component or the final consumer actually needs.

OUTPUT FORMAT
1. Which fix you applied and, explicitly, why each earlier option in the fix order did not fit — do not skip straight to the answer without showing the elimination.
2. The updated component tree with the fix applied, as real code.
3. The props list for each affected component, shown before and after — the actual point of the exercise is a visibly shorter list, and if it isn't visibly shorter, say why.