State architecture

Five kinds of state

"State management" is not one problem. Naming the kind you have usually names the tool.

The single biggest improvement most React codebases can make is moving rows three and four out of useState. Filters belong in the URL; server data belongs in a cache that knows about staleness.

The three questions before adding state

1. Can it be derived? If it can be computed from props or other state, compute it. Do not store it.
2. Does the UI change when it changes? If not, it is a ref.
3. Who needs it? Put it at the closest common ancestor of everyone who reads it — and no higher.

const [items, setItems] = useState([]);
const [count, setCount] = useState(0);          // ✗ derived — will drift
const [selectedItem, setSelectedItem] = useState(null);  // ✗ a whole copy

const count = items.length;                     // ✓
const [selectedId, setSelectedId] = useState(null);
const selectedItem = items.find((i) => i.id === selectedId);   // ✓ always fresh

Storing the selected object rather than its id is the classic duplication bug: edit the item in the list and the selection still shows the old version, because they are two separate copies now.

Shape it so bad states cannot exist

// ✗ 16 combinations, 4 of them valid
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);
const [data, setData] = useState(null);

// ✓ 4 states, and they are the 4 that exist
const [state, setState] = useState({ status: "idle" });
// { status: "loading" } | { status: "error", error } | { status: "ready", data }

With separate flags, "loading and also has an error" is one forgotten setter away, and the UI that results is genuinely confusing. With a status field it is unreachable. useReducer is the natural home for this once there are more than two transitions.

Normalise when things reference each other

// ✗ the same author object copied into every post
posts: [{ id: 1, author: { id: 9, name: "Ana" } }, ...]

// ✓ one copy, referenced by id
posts: { 1: { id: 1, authorId: 9 } },
authors: { 9: { id: 9, name: "Ana" } }

Renaming Ana now touches one place instead of every post she wrote. Lookups become O(1). This is a database idea and it applies for the same reason: duplicated data drifts.

Do not normalise a list of twenty things you render once. Normalise when the same entity appears in several places, or when you update items by id.

Colocation: the default that keeps apps fast

State at the top of the tree re-renders everything below it. State next to where it is used re-renders one subtree. The instinct to "lift it up in case something else needs it" is what makes an app slow and its components untestable.

function App() {
  const [isMenuOpen, setMenuOpen] = useState(false);   // ✗ whole app re-renders
}

function Menu() {
  const [isOpen, setOpen] = useState(false);           // ✓ only the menu
}

Lift when two components genuinely need the same value; push it back down the moment only one does.

A decision tree

The refactor that fixes most apps

Take a component with eight useState calls. Usually two of them are derived and can be deleted, two belong in the URL, three are server data that should be one query, and one is genuinely local. Eight becomes two, and the effects that were keeping them in sync disappear with them.