A React component holds request state as { status, data, error } with status typed 'idle' | 'loading' | 'success' | 'error'. TypeScript still lets you read data while status is 'error'. How would you model the state so each status carries exactly the data that state has?

## What is still wrong with the flat shape Collapsing three booleans into one `status` field removes the contradictory-flag problem, but it leaves a weaker version behind. This type: ```typescript type State<T> = { status: 'idle' | 'loading' | 'success' | 'error'; data: T | null; error: Error | null }; ``` says that *every* state may carry data and may carry an error. Two consequences follow. First, illegal values still type-check: `{ status: 'success', data: null, error: someError }` compiles fine. Second, and more annoying day to day, every consumer must defend against fields that are guaranteed present in their branch — you end up writing `state.data?.length ?? 0` inside the success case, where `data` cannot possibly be missing. ## The discriminated union A discriminated (tagged) union is a union of object types that all share one literal-typed field — the discriminant. Checking that field tells the compiler which member you are holding: ```typescript type RequestState<T> = | { status: 'idle' } | { status: 'loading' } | { status: 'success'; data: T } | { status: 'error'; error: Error }; ``` The payload now belongs to the state rather than to the container. `data` exists only where it is meaningful; `error` exists only where it is meaningful; `idle` and `loading` carry nothing at all, which is exactly true of them. There is no `null` in the type, because absence is expressed by being in a different variant. ## Narrowing at the use site Inside a `switch` on the discriminant, TypeScript narrows the value to the matching member: ```typescript switch (state.status) { case 'success': return renderList(state.data); // data: T, not T | null case 'error': return renderError(state.error); // error: Error, no optional chaining default: return null; } ``` The same narrowing works with an `if (state.status === 'success')` guard. This is where most of the ergonomic win lives: the null checks were never really checking anything, they were satisfying a type that was looser than reality. You can also make the branch exhaustive. Assigning the narrowed value to a `never` in the default arm turns "someone added a fifth state" into a compile error rather than a silently missing UI: ```typescript function assertNever(x: never): never { throw new Error(`Unhandled state: ${JSON.stringify(x)}`); } ``` ## Why it changes how you write transitions With the flat shape the tempting update is a partial spread: `setState(prev => ({ ...prev, status: 'loading' }))`. That is exactly how the previous request's `data` survives into the next load. With a union you cannot spread your way from one variant to another — the compiler rejects a `loading` object that still carries a `data` field only if you declare the variants exactly, and in practice you write `setState({ status: 'loading' })`, replacing the whole value. The type nudges you toward the correct transition. This is also why the union pairs well with holding the state in a reducer: a reducer returns a fresh state object per transition by construction, and its return type being the union means every branch must produce a complete, legal state. ## Where it is worth it, and where it is not The union earns its keep when different states genuinely carry different payloads, and when several components read the state. A refresh flow is a good stress test: if your UI must show the previous list while a refresh is in flight, then "stale data during loading" is a *legal* state, and you should model it as such — for example a `{ status: 'loading'; previous?: T }` variant — instead of quietly reverting to nullable fields everywhere. The point of the exercise is to enumerate the states you actually have, not to force a textbook four. In plain JavaScript, without a type checker, the same shape is still useful as a convention — payloads live under the status they belong to, and transitions replace the object — but nothing enforces it, so the reducer becomes the only place that guarantees the invariant. That is an argument for putting the transitions in one function rather than scattering them across handlers.