Reducers and Complex State

## Why flags multiply Every independent boolean doubles the number of states your component can be in. Three booleans give eight combinations; four give sixteen. An async request, however, has about four meaningful states: nothing requested yet, in flight, finished successfully, finished with an error. So with three booleans you are carrying eight slots to express four ideas, and the extra four slots are all *illegal*: they describe situations the domain does not have. ```typescript // all of these type-check, none of them are meaningful { isLoading: true, isError: true, isSuccess: false } { isLoading: false, isError: false, isSuccess: true, data: null } { isLoading: true, isError: false, isSuccess: true } ``` The compiler cannot help, because nothing in the type says the three fields are related. The invariant lives only in your head and in the discipline of every setter. ## How the bug actually shows up The classic failure is a retry. The first attempt fails, so the handler sets `isError` to `true` and stores `error`. The user clicks Retry, and the handler sets `isLoading` back to `true` — but forgets `setIsError(false)` and forgets to clear `error`. Now the render tree hits `if (error) return <ErrorBanner/>` before it ever reaches the spinner branch, and the user sees the old failure while a new request is in flight. Nobody wrote a bug; somebody forgot a line. The second failure is ordering. Because the flags are separate pieces of state, the component's *render order* silently becomes the state machine: whichever `if` you check first wins when two flags disagree. Move the `if (isLoading)` branch above the `if (error)` branch during a refactor and the visible behaviour changes without any state change. ## The single-status model Collapse the flags into one field whose values are the states themselves: ```typescript type Status = 'idle' | 'loading' | 'success' | 'error'; const [status, setStatus] = useState<Status>('idle'); ``` Now a transition is one assignment. `setStatus('loading')` cannot leave a stale `error` flag behind, because there is no separate flag to leave behind — the previous state is *replaced*, not partially overwritten. Rendering becomes an exhaustive branch: ```typescript switch (status) { case 'idle': return null; case 'loading': return <Spinner/>; case 'error': return <ErrorBanner/>; case 'success': return <List/>; } ``` In TypeScript the union type also makes the branch checkable: add a fifth state and every `switch` that does not handle it can be made to fail the build. This is what "make impossible states unrepresentable" means in practice — you shrink the state space to exactly the legal states, so the class of bug disappears rather than being tested for. Derived booleans are still fine at the point of use. `const isBusy = status === 'loading'` is a read-only convenience computed from the one source of truth; the problem was never the word `isLoading`, it was storing it independently. ## Where the state lives For a single status plus payload, one `useState` holding an object is usually enough. Once transitions start depending on the current state — "a SUBMIT while already submitting must be ignored" — a reducer is the better home, because the transition logic then sits in one function instead of being spread across handlers. Either way, the important part is that the four fields move together as one value. A useful smell test in review: if two `set*` calls always have to happen together for the component to be correct, they are one piece of state that has been split by accident. ## React 19 note For form submissions you often do not model the pending state yourself at all — React 19's action-based APIs surface a pending flag for you. The flag-soup problem chiefly bites hand-rolled async state: data you fetch and store in a component, multi-step flows, and anything with more outcomes than "pending or not".