Frontend Beauty
ESC

Type to search the knowledge base.

State Colocation

Keep state as close as possible to where it is used: colocation, lifting when shared, and re-render blast radius.

intermediate3 min read
  • react
  • state-colocation

State colocation means storing state in the nearest component that reads or updates it — not defaulting everything to the app root “for flexibility.” Local state keeps re-renders small, APIs honest, and mental models simple.

It is the dual of lifting state up: lift only when two or more siblings must coordinate.

Docs: Choosing the State Structure, Sharing State.

Local until proven shared

function FilterableList({ items }) {
  return (
    <div>
      {/* query only affects list chrome — keep it here, not in Redux */}
      <ListSection items={items} />
      <Footer />
    </div>
  );
}

function ListSection({ items }) {
  const [query, setQuery] = useState('');
  const filtered = items.filter((i) => i.name.includes(query));
  return (
    <>
      <input
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        aria-label="Filter"
      />
      <ul>
        {filtered.map((i) => (
          <li key={i.id}>{i.name}</li>
        ))}
      </ul>
    </>
  );
}

Typing in the filter does not re-render Footer. That is colocation winning without memo.

Re-render blast radius

State lives on a fiber. Updating it re-renders that fiber and, by default, its descendants. Higher state ⇒ larger trees re-render.

// Wide blast: every keystroke re-renders the whole page shell
function Page() {
  const [q, setQ] = useState('');
  return (
    <>
      <ExpensiveNav />
      <input value={q} onChange={(e) => setQ(e.target.value)} />
      <Results q={q} />
    </>
  );
}

Move q into a child that owns both input and results, or split the tree so ExpensiveNav is not under the stateful parent.

Forms and wizards

Ephemeral field state can stay in the field until submit. Durable answers for a multi-step wizard lift to the wizard parent (or a reducer) while each step’s UI chrome stays local — see multi-step forms.

Colocation versus URL and server

Kind of state Home
Hover / open / draft char Local component
Selected tab affecting deep links URL search params
Shared session user Context / auth layer
Product list from API Server / query library near consumer

Colocation is not “never global.” It is “do not globalize by default.”

Interview out-loud

“I colocate state with the components that use it to minimize re-render blast radius and keep ownership clear. I lift when siblings must share a source of truth, and I put cross-cutting session data in context or a store. URL state is for shareable UI.”

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