Lifting State Up

Introduction

React state is local by default — it belongs to whichever component called useState. That isolation is usually a good thing, but it creates a specific problem the moment two sibling components need to reflect the very same piece of data. Neither sibling can reach into the other's state, because React data only flows one way: from parent to child through props.

Lifting state up is the standard React pattern for this situation: instead of each sibling owning its own copy of the data, the state is moved up to their closest common parent, which then hands it back down to both siblings as props — along with a function they can call to update it. This lesson walks through the problem, the fix, and a complete worked example.

The Problem: Siblings Cannot Share State

Imagine two components, TemperatureInputC and TemperatureInputF, each rendering an input box. If each one manages its own useState independently, typing in one has no effect on the other — even though conceptually they represent the same temperature in two different units.

function TemperatureInputC() {
  const [value, setValue] = useState('');
  return <input value={value} onChange={(e) => setValue(e.target.value)} />;
}

function TemperatureInputF() {
  const [value, setValue] = useState('');
  return <input value={value} onChange={(e) => setValue(e.target.value)} />;
}

function App() {
  return (
    <div>
      <TemperatureInputC />
      <TemperatureInputF />
    </div>
  );
}

Typing "100" into the first input
leaves the second input completely unchanged.
The two components have no way to see each other's state.

This is not a bug — it is exactly how React is designed to work. State is private to the component that owns it. The fix is not to find a way to "reach across" from one sibling to the other; it is to stop storing the value in either sibling at all.

The Fix: Move State to the Common Parent

The solution is to identify the closest common ancestor of the components that need to share data — here, that is App — and move the useState call there instead. The parent then passes the current value down to both children as a prop, along with a function each child can call to request a change.

Worked Example: Two Synced Inputs

Let's fix the temperature example by lifting the shared value up into App, and passing it down to both inputs as props.

import { useState } from 'react';

function SyncedInput({ label, value, onChange }) {
  return (
    <label>
      {label}:
      <input value={value} onChange={(e) => onChange(e.target.value)} />
    </label>
  );
}

function App() {
  // The single source of truth now lives in the parent.
  const [sharedValue, setSharedValue] = useState('');

  return (
    <div>
      <SyncedInput label="Input A" value={sharedValue} onChange={setSharedValue} />
      <SyncedInput label="Input B" value={sharedValue} onChange={setSharedValue} />
      <p>Current value: {sharedValue}</p>
    </div>
  );
}

export default App;

Input A: [ hello ]
Input B: [ hello ]
Current value: hello

(typing in either input updates BOTH instantly)

Neither SyncedInput calls useState at all — it simply receives value and onChange as props. Because both instances read from the exact same sharedValue in App, and both call the exact same setSharedValue function, they can never drift out of sync.

When to Lift State (and When Not To)

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

Lifting state up turns two independent, out-of-sync components into two views of a single source of truth. By moving useState to the closest common parent and passing the value and its setter down as props, siblings can share data reliably without ever talking to each other directly.

In this lesson, you saw why sibling state cannot be shared directly, learned the lifting pattern, and built two inputs that stay perfectly in sync through a shared parent. Next, you will look at prop drilling — what happens when the common parent sits many layers above the components that need the data.