Frontend Beauty
ESC

Type to search the knowledge base.

Lifting State Up

Share state by moving it to the closest common parent: when to lift, how to pass setters, and when context is better.

beginner3 min read
  • react
  • lifting-state

Two siblings need the same data. Each keeps a private copy and they drift out of sync. Lift state up: store the value in the nearest common parent, pass data down as props, and pass callbacks to request changes.

This is the backbone of React data flow: one source of truth, props down, events up.

Docs: Sharing State Between Components.

function SearchPage() {
  const [query, setQuery] = useState('');

  return (
    <div>
      <SearchInput query={query} onQueryChange={setQuery} />
      <ResultCount query={query} />
      <ResultList query={query} />
    </div>
  );
}

function SearchInput({ query, onQueryChange }) {
  return (
    <input
      value={query}
      onChange={(e) => onQueryChange(e.target.value)}
      aria-label="Search"
    />
  );
}

function ResultCount({ query }) {
  const count = useMemo(() => filter(query).length, [query]);
  return <p>{count} results</p>;
}

query lives once. Children are controlled or pure projections. No effect mirrors the input into three places.

How high is high enough?

Lift to the lowest common ancestor that needs to coordinate, not always the app root.

Situation Where state lives
Input + its validation message Same form field component
Filter bar + list Page or feature parent
Theme / auth user Context or store near root
Modal open flag used once Local until a remote trigger appears

Over-lifting causes prop drilling and unnecessary re-renders of large subtrees. Under-lifting duplicates state. State colocation is the dual skill: keep state local until sharing is required.

Controlled versus notify-parent

// Fully controlled
<DateField value={date} onChange={setDate} />

// Parent owns commit; child keeps a draft
function DateField({ value, onChange }) {
  const [draft, setDraft] = useState(value);
  return (
    <>
      <input value={draft} onChange={(e) => setDraft(e.target.value)} />
      <button type="button" onClick={() => onChange(draft)}>Apply</button>
    </>
  );
}

Prefer fully controlled forms that submit as one unit. Local draft state is fine for heavy editors if you define reset and commit rules — and often remount with key when the entity changes (resetting state).

When lifting is the wrong tool

  • Deep tree with many consumers → context or a store (context performance).
  • Independent UI that only looks related → keep local.
  • Server data → fetch library or RSC, not “lifted useState of the world.”
  • Prop drilling pain → composition with children slots.

Interview out-loud

“When two components need the same changing data, I lift state to their closest common parent and pass value plus onChange down. I lift only as high as coordination requires. For cross-cutting data I use context or a store instead of threading props through every layer.”

Further reading

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