Keep React State Where the Decision Is Made

A practical approach

Step 1

For each piece of state, name the component that changes it and the components that read it.

Step 2

Place the state in the lowest component that contains all of those readers and writers.

Step 3

Pass values down as props and pass callbacks for changes, named after the user's intent such as onFilterChange rather than setState.

Step 4

Derive values during rendering instead of storing them. A filtered list computed from items and a query does not need its own state.

Step 5

Reach for context or a store only for values many distant components read, such as the signed-in user or theme, not for one form's input.

Worked example

A course catalogue keeps the search text, selected category, sort order and the filtered results in a top-level App component, plus a copy of the filtered results in a global store. Typing a letter re-renders the header, footer and sidebar, and the two copies of the results sometimes disagree. Moving the filters into the Catalogue component and computing the results during rendering removes the duplicate state and limits re-renders to the part of the page that changed.

A mistake to avoid

Avoid storing props in state with const [items, setItems] = useState(props.items). The local copy stops updating when the parent's data changes, which creates bugs that appear only after the second navigation.

Try it yourself

Pick one page in a React project and draw its components as a tree. Mark where each piece of state lives and which components read it. Move at least one value lower or remove one derived value from state, then confirm the page still behaves correctly.

Your implementation checklist

• Each piece of state has one clear owner component
• State is lifted only to the closest common parent
• Derived values are computed, not stored
• Callbacks describe user intent
• Global stores hold only widely shared values