State Machine Patterns

Boolean flags feel convenient until they multiply. isLoading, isError, isSuccess, and isRetrying create sixteen possible combinations, but most are invalid. State machines replace flag soup with explicit named states and allowed transitions.

Named States

Start by naming what the UI can actually be. An async request might be idle, loading, success, error, or retrying. Each event moves from one state to another only if that transition is allowed.

type FetchState = "idle" | "loading" | "success" | "error" | "retrying";
type FetchEvent = "FETCH" | "RESOLVE" | "REJECT" | "RETRY" | "RESET";

const transitions: Record<FetchState, Partial<Record<FetchEvent, FetchState>>> = {
  idle: { FETCH: "loading" },
  loading: { RESOLVE: "success", REJECT: "error" },
  success: { RESET: "idle", FETCH: "loading" },
  error: { RETRY: "retrying", RESET: "idle" },
  retrying: { RESOLVE: "success", REJECT: "error" },
};

export function transition(state: FetchState, event: FetchEvent): FetchState {
  return transitions[state][event] ?? state;
}

Invalid transitions do nothing, which prevents impossible states such as loading and success at the same time.

Minimal Hook Shape

In React, a small hook can wrap this transition table. In Svelte or nanostores, the same transition function can sit in a shared store.

import { useCallback, useState } from "react";

export function useStateMachine<TState extends string, TEvent extends string>(
  initialState: TState,
  table: Record<TState, Partial<Record<TEvent, TState>>>,
) {
  const [state, setState] = useState(initialState);

  const send = useCallback((event: TEvent) => {
    setState((current) => table[current][event] ?? current);
  }, [table]);

  return { state, send };
}

For complex flows, XState adds guards, actions, invoked services, actors, parallel states, and visual tooling. Reach for it when the statechart is central to the product, such as onboarding, checkout, collaborative editing, or multi-step approvals.

Further Learning

Search these terms to go deeper:

• “finite state machines UI state” — modeling interfaces as states and events
• “XState guards actions actors” — full-featured statechart architecture
• “boolean flag antipattern frontend” — recognizing impossible UI combinations
• “statechart multi step form” — applying machines to user flows

State Machine Patterns

Ever had a bug where a loading spinner shows and an error message shows at the same time? That happens when you track UI status with a pile of separate true/false flags. A state machine fixes this by saying: the UI is in exactly one named state at a time.

The problem: flag soup

Say you track a data fetch with booleans:

isLoading, isError, isSuccess, isRetrying

Four flags = 16 possible combinations — but most are nonsense (loading and success?). It’s easy to accidentally set two at once and get a weird UI.

The fix: one state at a time

Instead of flags, name the states the UI can actually be in, and only allow sensible moves between them:

type State = 'idle' | 'loading' | 'success' | 'error'

It can be loading or success, never both. You define which events move you where:

• From idle, a “fetch” event → loading
• From loading, “resolve” → success, or “reject” → error
• From error, “retry” → loading

Any move that’s not allowed simply does nothing — so you can’t end up in an impossible combination.

A tiny version

You can build this with a simple lookup table of “from this state, this event leads to that state.” No library required for simple cases. For big, complex flows (checkout, onboarding), a library called XState adds powerful tools and even visual diagrams.

In one sentence

A state machine models a UI as exactly one named state at a time (idle/loading/success/error) with defined transitions — replacing tangled boolean flags that let impossible combos like “loading and success” slip through.

Want to go deeper?

Switch to Expert mode above for a reusable useStateMachine hook, the full transition table, and when to reach for XState.