Stop Using isLoading Booleans in TypeScript

Four booleans and one optional field give you 32 possible states. Your app has 4. The other 28 are bugs TypeScript will happily let you write. In this one I refactor a classic isLoading / isError / data type into a discriminated union, and show how narrowing, exhaustive never checks, and satisfies make impossible states impossible to write. Then the same pattern for Result types, reducers, and order state machines, plus the gotchas that quietly break narrowing. Chapters 0:00 32 states, 4 real ones 1:30 The fix: discriminated unions 2:50 Exhaustiveness with never 4:30 Beyond UI state: Result, reducers, state machines 5:35 Gotchas that break narrowing 6:40 The rule Code shown in the video type RequestState = | { status: "idle" } | { status: "loading" } | { status: "success"; data: User } | { status: "error"; error: Error }; Links to resources: TypeScript Handbook, Narrowing: https://www.typescriptlang.org/docs/h... typescript-eslint switch-exhaustiveness-check: https://typescript-eslint.io/rules/sw... #typescript #webdev #react