Sharing State by Lifting It Up

You have built components that own their own state in the React for Beginners series. Now comes the scenario every real application hits: two sibling components need to reflect the same changing value. The answer is a principle called lifting state up — move the shared state to their closest common ancestor and pass it down, along with the functions that update it.

The problem: siblings that disagree

Imagine a product page with a search box and a results list. Each component starts with its own state, and nothing synchronises them:

function SearchBox() {
  const [query, setQuery] = useState('');      // state lives here…
  return <input value={query} onChange={(e) => setQuery(e.target.value)} />;
}

function ResultsList() {
  const [query, setQuery] = useState('');      // …and a separate copy here
  // never sees SearchBox's value ❌
}

Expected output: typing "vite" filters nothing — the list component has no idea the other state exists. Duplicated state always drifts out of sync.

Lift it to the common parent

Move the single source of truth up to the component that renders both. The parent owns the state; children receive what they need through props:

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

  const visible = products.filter((p) =>
    p.name.toLowerCase().includes(query.toLowerCase()),
  );

  return (
    <section>
      <SearchBox value={query} onChange={setQuery} />
      <ResultsList items={visible} />
    </section>
  );
}

Expected output: typing "vite" in the box immediately narrows the list to matching products. One state, one owner, two consumers — both stay consistent because they read the same value.

Props down, callbacks up

The pattern has a rhythm worth memorising. Data flows down from parent to child through props; updates flow up through callback functions the parent passes down:

A child stays "dumb": it renders what it is given and reports what happened. The parent decides what it means. That separation is what makes components reusable.

State should live where it is used

React's documentation offers a reliable test for choosing the right owner. Ask two questions about every piece of state:

1. Is it used by only one component? Then keep it local — right there in that component.
2. Is it used by several components, or will it be? Then lift it to their closest shared ancestor.
3. Can it be computed from existing state or props? Then do not store it at all — derive it during render (as visible is derived from query above).

Deriving instead of duplicating eliminates the classic bug where a stored copy is forgotten during an update.

A worked example: the temperature converter

The canonical demonstration is two inputs that must agree. Editing either one recalculates the other from shared state in the parent:

function TemperatureConverter() {
  const [celsius, setCelsius] = useState('');

  const fahrenheit = celsius === '' ? '' : (parseFloat(celsius) * 9) / 5 + 32;

  return (
    <form>
      <input value={celsius} onChange={(e) => setCelsius(e.target.value)} />
      <output>{fahrenheit}°F</output>
    </form>
  );
}

Expected output: entering 100 shows 212°F; entering 37 shows 98.6°F; clearing the input clears the output. There is only one state — fahrenheit is derived, never stored, so it can never disagree.

When lifting gets awkward

Passing state and callbacks through many layers — prop drilling — works fine for a few levels but grows noisy in deep trees. Two honest coping strategies:

• Compose instead of drill — sometimes a component can accept children or callbacks as props and skip a layer entirely (chapter 14).
• Move truly global state to context — themes, current user and locale belong to React context, not an eight-level prop chain.

Neither replaces this chapter's principle: shared state still has one owner; you are only changing how widely it is published.

Common mistakes

• Duplicating state in both children — two copies always drift; keep one in the parent.
• Mutating the child's copy — a child that edits the object it received as a prop breaks the parent's data; call the parent's callback instead.
• Storing derived values — computed-from-state data (counts, filters, totals) belongs in a calculation, not a second useState.
• Passing a whole object when a slice will do — pass just the fields the child needs; unrelated changes then skip needless re-renders.
• Lifting too eagerly — state used by exactly one component has no reason to move up; local state keeps components self-contained.

Practice checklist

1. Rebuild the search-and-results pair, starting with duplicated state, then lift it to the parent.
2. Add a "results count" component that also reads the shared query — confirm all three stay in sync.
3. Write the temperature converter with one state and a derived value; verify all expected outputs.
4. Refactor one stored value that could be computed into a plain derivation during render.
5. Draw your component tree and mark where the shared state lives now.

Shared state updates work — but some state changes should happen automatically. That is the job of Effects with useEffect.