Lifting state up means moving state from a child component to a common parent so that multiple children can share and stay in sync with the same data. It's the standard solution when sibling components need to coordinate.
() { [temp, setTemp] = (); ... }
If two sibling components each hold their own copy of related state, there's no way for them to stay consistent — changing one doesn't affect the other.
function Calculator() {
const [temperature, setTemperature] = useState(0); // state LIFTED to the parent
return (
<>
{/* pass state DOWN as a prop, and a setter to update it */}
<TempInput scale="C" value={temperature} onChange={setTemperature} />
<TempInput scale="F" value={temperature} onChange={setTemperature} />
<p>Both inputs share one value: {temperature}</p>
</>
);
}
function TempInput({ value, onChange }) {
return <input value={value} onChange={e => onChange(e.target.value)} />;
}
The shared state now lives in the parent (Calculator). It passes the value down as a prop and a setter so children can request changes (up). Now both inputs reflect the same source — editing one updates both.
1. Find the closest COMMON ancestor of the components that need to share
2. Move the state UP into that ancestor
3. Pass the value DOWN as props
4. Pass a callback DOWN so children can request updates (data up via events)
This is the same "data down, events up" flow, applied to make state shared.
Lifting too high (state ends up far from where it's used) → prop drilling.
At that point, prefer Context or a state library instead of lifting further.
Lifting state up is the fundamental technique for sharing state between sibling/related components in component-based frameworks — it keeps a single source of truth in a common parent so the children stay in sync.
It's often the first tool to reach for before adding Context or a store.
Recognizing when to lift (siblings need to coordinate) — and when lifting has gone too far (causing prop drilling, so it's time for Context/a store) — is core to structuring component state well.