State
State is the value a component remembers between renders. When user input, timers, or async results change something important, React stores the new state and uses it to calculate the next UI.
▶Architecture Diagram
🔄 ProcessDashed line animations indicate the flow direction of data or requests
Static props alone cannot model interfaces that evolve as users interact with them. Without a place to keep the current selection, input, or open-closed status, the UI would reset every time the component function runs.
Before declarative UI models became common, teams often scattered current values across DOM nodes and ad hoc mutable variables. That worked for small pages, but became difficult to reason about once many interactions overlapped. React moved the center of gravity to state so UI could be described from current values instead of direct DOM patches.
During render, the component reads its current state and calculates JSX from it. When an event handler calls a state setter, React queues the next state snapshot. On the next render, React reads that new value and computes the next UI from it.
The basic flow of updating state from user input
import { useState } from "react";
export function Counter() {
const [count, setCount] = useState(0);
return (
<div>
<p>Current value: {count}</p>
<button onClick={() => setCount(count + 1)}>
Increment
</button>
</div>
);
}A button click updates state, and the next render recalculates the UI from the new value.
State is read in the current render while the setter schedules the next one
function SearchBox() {
const [query, setQuery] = useState("");
function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
setQuery(event.target.value);
}
return (
<>
<input value={query} onChange={handleChange} />
<p>Query: {query}</p>
</>
);
}When an input is backed by state, the screen is always rendered from the latest state snapshot.
State differs from props because props come from outside while state is owned locally. It also differs from refs because state is for values that should affect rendering, while refs can store values without triggering another render. Controlled form inputs are one concrete pattern built on top of state.
In practice, the most important question is not whether to use state, but where to place it. Put it too high and unrelated parts of the tree rerender. Put it too low and sibling components cannot share it when needed.