State Colocation

State colocation means keeping state in the lowest component in the tree that genuinely needs to read or update it. This reduces unnecessary sharing, keeps ownership clear, and can limit the scope of updates.

When several components need the same state, place that state in their lowest common ancestor rather than automatically putting it in a global store or a high-level component. The ancestor can then pass the value and relevant update operations to its descendants.

For example, if two sibling components both need a selected item, their parent is usually the natural owner. If only one component needs the value, keeping it locally avoids unnecessary props and state propagation.

Colocation is also useful for derived state and UI-specific state. A modal's open state, an input's draft value, or a temporary selection often belongs close to the component that controls that behavior. State should move upward when another component needs it, not merely because lifting it is technically possible.

The goal is not to minimize the number of state variables or always keep state as low as possible. The practical rule is to place state at the lowest common owner that can satisfy all current consumers, while considering boundaries such as reusable components, routing, context, server state, and application-wide concerns.

Key points

• Keep state at the lowest common component that needs to read or update it.
• Keep truly local UI state inside the component that owns the behavior.
• Lift state only when multiple components need coordinated access to it.
• Avoid putting local state in global stores without a concrete sharing requirement.
• Derived values should generally be computed from existing state rather than duplicated as separate state.

Interview questions

What is state colocation, and why is it useful?

State colocation means keeping state close to the components that actually use it. If only one component needs a value, that component is usually the appropriate owner. If several siblings need it, their lowest common ancestor can own the state. This keeps ownership understandable and avoids unnecessarily broad state scope.

How do you decide where a piece of React state should live?

First identify every component that must read or update the value. If there is one consumer, keep the state there; if multiple related consumers exist, place it in their lowest common ancestor. Then consider whether the value crosses a meaningful application boundary that makes Context or another state mechanism appropriate. I would avoid moving state higher until an actual sharing requirement justifies it.

What problems can result from putting too much state high in the component tree?

A high-level owner can force unrelated components to receive props or participate in updates. It can make dependencies harder to understand because components become coupled to state they do not conceptually own. It may also broaden the scope of rendering work when state changes. The solution is usually to move state closer to its actual consumers unless a wider scope is intentional.

Is state colocation primarily a performance optimization?

No; its primary benefit is clearer ownership and narrower dependencies. Narrowing state scope can also reduce the number of components affected by updates, but rendering behavior depends on the framework and component structure. A well-colocated design can therefore help performance, but it should not be treated as a substitute for measuring actual bottlenecks. The architectural question is first about responsibility and data flow.

How is colocated state different from derived state?

Colocated state describes where a mutable source of truth is owned. Derived state describes a value that can be calculated from existing state or props. If a value can reliably be computed from existing data, storing another copy can introduce synchronization problems. The location of the source state and the calculation of derived values are separate design decisions.