Learning on Web Dev Open is free for all.

Framework Internals > State, by where it livesMost state bugs are modelling bugs
Phase 04State, by where it lives197 of 434

Most state bugs are modelling bugs

Before choosing a state library, ask which of four places each piece of state actually belongs in. Usually two of them turn out not to be state at all.

Concept14 minAI pair

Four homes. Local state belongs to one component and nothing else needs it: an open dropdown, a hovered row. Derived state is not state at all, it is a function of something else and should be computed. Server state is a cache of something that lives elsewhere and can change without you. URL state is what should survive a refresh, a bookmark and a shared link.

The bugs come from putting something in the wrong home. A filter kept in local state means the link you send a colleague shows them something different. A total kept in state alongside the items means the two can disagree. A fetched list kept in a global store means you have hand-written a cache with no invalidation, which is the hardest thing in this phase and you have done it by accident.

Do the classification before reaching for a library. In most features half the useState calls turn out to be derived values and a third of the rest want to be in the URL, and what remains is small enough that the choice of library stops mattering much. That is the goal: make the question boring rather than answering it well.

You should now be able to

  • Classify each piece of state by where it belongs
  • Explain why duplication is the root of most sync bugs
Ask the community

Loading…