A value is threaded as an input through five components that only forward it; what does that cost, and how do you choose a remedy?

## First, price the threading honestly Passing a value down through levels that do not use it is the default, and the default has real virtues: the path is visible in the code, every dependency is declared, and there is no machinery to learn. A two-level hop is not a problem, and "fixing" it usually costs more than it saves. What makes a long chain expensive is worth naming precisely, because each cost points at a different remedy. - **The intermediate contracts lie.** A component that declares an input purely to forward it advertises a dependency it does not have. Readers cannot tell a forwarder from a consumer. - **Reuse narrows.** That component can no longer be rendered anywhere the value does not exist, even though it never reads it. - **Tests carry ballast.** Every test of an intermediate level must supply values it does not use, and those arguments have to be maintained. - **Change amplifies.** A rename, a shape change or an added sibling value edits every level in the chain, so a small contract change produces a wide diff. - **Consumers become invisible.** With the value present at five levels, nobody can answer "who actually reads this?" without tracing the whole chain. If you cannot point at two or three of those costs in the code in front of you, the chain is fine. ## The three remedies and what each one is for | remedy | what it changes | best when | what you give up | |---|---|---|---| | restructure the composition | the consumer is created where the data already is, and handed to the intermediate levels as content | the chain exists only because the consumer sits deeper than it needs to; the intermediates are generic containers | the owner now knows what the subtree renders, so the layout is less freely rearranged from below | | provide the value to a subtree | the value becomes available to a bounded region without passing through each level | many components under one boundary read it; the boundary is a real product concept, such as a screen or a form | the dependency is implicit — a consumer can be rendered outside the boundary, and readers no longer see the path | | keep the value outside the tree | readers subscribe to it wherever they are | it is app-wide, outlives any one screen, and unrelated subtrees read and write it | lifetime and teardown become your problem, and "who changed this?" is a wider question | ## The questions that actually decide it 1. **How long is the chain, and is it stable?** Five levels that have not moved in a year hurt less than three that are rearranged every sprint. 2. **Who owns the intermediate levels?** If they are library components you do not own, you cannot add inputs to them, and restructuring or subtree provision are your only options. 3. **How many consumers, and where?** One deep consumer argues for restructuring; many under one boundary argue for subtree provision; scattered consumers across unrelated boundaries argue for out-of-tree state. 4. **How discoverable must the dependency be?** The more a value's flow needs to be auditable — permissions, money, anything a reviewer must reason about — the more the explicit chain earns its cost. 5. **What is the value's lifetime?** Something tied to one screen should not outlive it. A value that must survive navigation is a poor fit for anything scoped to a subtree that unmounts. 6. **Does it cross a package or team boundary?** An implicit ambient dependency across an ownership boundary becomes a support burden: the consumer fails in a context its authors never tested. ## The failure modes of each remedy - **Restructuring too eagerly** pushes layout decisions upward until the top component knows everything about every screen. The container that was reusable becomes a script. - **Subtree provision as a habit** ends with components that cannot be rendered anywhere except inside one specific ancestor, and with nothing in their contract saying so. The diagnostic question is whether a consumer fails intelligibly outside the boundary. - **Out-of-tree state as the default** makes every value global, so no value has a lifetime and two screens share what they should not. It also moves the debugging question from "which parent passed this?" to "which of forty writers wrote this?". ## How to lead the decision State the rule for the codebase rather than deciding case by case. A workable house rule: thread it while the chain is short and the intermediates are honest; restructure when the chain exists only because the consumer is placed too deep; provide to a subtree when the boundary is a real product concept and multiple consumers live inside it; go outside the tree only for values that genuinely outlive the screen. Write down the chain length at which you stop threading, so the decision is not relitigated in every review, and accept that the number is a judgment call — the point is consistency, not precision. One more thing worth saying out loud in a review: the discomfort of a long chain is often a symptom of the consumer being in the wrong place, not of the threading mechanism being inadequate. Check the tree shape before reaching for machinery.