TypeScript and Type Systems for Frontend Engineers (2026)

Discriminated unions for state machines

Discriminated unions are the canonical TypeScript pattern for modeling finite-state machines. The pattern: each state has a literal-typed discriminator (commonly named status or kind) plus state-specific fields. The compiler narrows the type inside switch / if blocks based on the discriminator.

type AsyncResult<T, E = Error> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; error: E };

function handleResult<T, E>(result: AsyncResult<T, E>): string {
  switch (result.status) {
    case "idle":
      return "Not started";
    case "loading":
      return "Loading\u2026";
    case "success":
      // result is narrowed to { status: "success"; data: T } here.
      return \`Got: ${JSON.stringify(result.data)}\`;
    case "error":
      // result is narrowed to { status: "error"; error: E } here.
      return \`Error: ${result.error}\`;
    default: {
      // Exhaustiveness check — result is "never" here. If a new state
      // is added to the union without handling, TypeScript flags this.
      const _exhaustive: never = result;
      throw new Error(\`Unhandled state: ${_exhaustive}\`);
    }
  }
}

What this pattern gets right: invalid states are unreachable (you cannot have a data field while status === "loading"); the compiler narrows the type inside each switch case, so you get type-safe access to state-specific fields; the never default branch enforces exhaustiveness — if you add a new state to the union without handling it, TypeScript errors.

The anti-pattern this replaces: type AsyncResult<T> = { data?: T; loading: boolean; error?: Error }. The anti-pattern allows { data: undefined, loading: true, error: someError } simultaneously — an invalid state that runtime code must defensively check. The discriminated union makes this state un-representable.

Mapped types and conditional types

Mapped types iterate over the keys of a type and transform each key. Conditional types branch on whether one type extends another. Together they form the toolkit for type-level programming in TypeScript.

// Built-in mapped types you should know:
//   Partial<T>     — make every property optional
//   Required<T>    — make every property required
//   Readonly<T>    — make every property readonly
//   Pick<T, K>    — pick a subset of properties
//   Omit<T, K>    — omit a subset of properties
//   Record<K, T>  — object with K keys, T values

type User = {
  id: string;
  name: string;
  email: string;
  passwordHash: string;
};

// PublicUser strips passwordHash without manually reauthoring the type.
type PublicUser = Omit<User, "passwordHash">;
//   { id: string; name: string; email: string }

// A custom mapped type — make every value type a Promise.
type AsyncFields<T> = {
  [K in keyof T]: Promise<T[K]>;
};

type AsyncUser = AsyncFields<User>;
//   {
//     id: Promise<string>;
//     name: Promise<string>;
//     email: Promise<string>;
//     passwordHash: Promise<string>;
//   }

// A conditional type — extract the resolved type from a Promise.
type Awaited<T> = T extends Promise<infer U> ? U : T;

type X = Awaited<Promise<number>>;  // number
type Y = Awaited<number>;            // number

// A more complex conditional — derive component prop types from a config map.
type ComponentConfig = {
  Button: { variant: "primary" | "secondary"; onClick: () => void };
  Input: { type: "text" | "email"; value: string };
  Modal: { isOpen: boolean; onClose: () => void };
};

type ComponentProps<K extends keyof ComponentConfig> = ComponentConfig[K];

type ButtonProps = ComponentProps<"Button">;
//   { variant: "primary" | "secondary"; onClick: () => void }

The senior+ pattern: derive types instead of duplicating them. If you find yourself manually authoring a type that's a transformation of another type, reach for mapped or conditional types instead. Matt Pocock's Total TypeScript course (totaltypescript.com) is the canonical practical reference.

The satisfies operator

The satisfies operator (TypeScript 4.9+) lets you check that a value conforms to a wider type while preserving the value's narrower inferred type. The pattern eliminates many "as const" / explicit-cast patterns and is increasingly common in modern TypeScript codebases.

The problem satisfies solves:

type RouteConfig = Record<string, { path: string; auth: boolean }>;

// Without satisfies — you must annotate the type to validate it,
// but you LOSE the literal type inference (the keys become string).
const routes: RouteConfig = {
  home: { path: "/", auth: false },
  dashboard: { path: "/dashboard", auth: true },
  settings: { path: "/settings", auth: true },
};

routes.home;          // OK — but type is { path: string; auth: boolean }
routes.unknownRoute;  // OK — TypeScript thinks any string key works.

// With satisfies — TypeScript validates the value matches RouteConfig
// AND preserves the literal type (so keys are narrowed to "home" | "dashboard" | "settings").
const routesWithSatisfies = {
  home: { path: "/", auth: false },
  dashboard: { path: "/dashboard", auth: true },
  settings: { path: "/settings", auth: true },
} satisfies RouteConfig;

routesWithSatisfies.home;             // OK
routesWithSatisfies.unknownRoute;     // ERROR — Property does not exist
routesWithSatisfies.home.auth;        // type is false (literal!) not boolean

The senior pattern: use satisfies for config objects, schema definitions, route maps, and any object where you want both validation against a wider type and preservation of the narrow literal types. The TypeScript 4.9 release notes (typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html) document the operator.

Generic constraints and type predicates

Two patterns that show up in senior+ TypeScript code: generic constraints (the extends keyword in generic parameters) and type predicates (the x is T return-type syntax for narrowing functions).

Generic constraints — restrict the shape a generic type parameter must satisfy:

// A generic function that requires T to have an "id" field.
function findById<T extends { id: string }>(
  items: readonly T[],
  id: string,
): T | undefined {
  return items.find((item) => item.id === id);
}

// A generic that uses keyof to constrain a key parameter.
function getValue<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user = { id: "u1", name: "Ada", email: "[email protected]" };
const name = getValue(user, "name");      // type is string
const id = getValue(user, "id");          // type is string
const bad = getValue(user, "unknownKey"); // ERROR

Type predicates — narrow a runtime type check into a TypeScript-known narrowing:

type ApiResponse =
  | { kind: "success"; data: unknown }
  | { kind: "error"; error: string };

function isSuccess(
  response: ApiResponse,
): response is { kind: "success"; data: unknown } {
  return response.kind === "success";
}

function handleResponse(response: ApiResponse) {
  if (isSuccess(response)) {
    // response is narrowed to { kind: "success"; data: unknown }
    console.log(response.data);
  } else {
    // response is narrowed to { kind: "error"; error: string }
    console.error(response.error);
  }
}

// Type predicate for runtime data validation:
type User = { id: string; name: string; email: string };

function isUser(value: unknown): value is User {
  return (
    typeof value === "object" &&
    value !== null &&
    "id" in value &&
    "name" in value &&
    "email" in value &&
    typeof (value as Record<string, unknown>).id === "string" &&
    typeof (value as Record<string, unknown>).name === "string" &&
    typeof (value as Record<string, unknown>).email === "string"
  );
}

function parseUserData(raw: unknown): User | null {
  return isUser(raw) ? raw : null;
}

The senior+ pattern: use type predicates for data-validation boundaries (API responses, localStorage reads, postMessage handlers). For complex schema validation, prefer zod (zod.dev) which produces type predicates as a side effect of schema definition. The TypeScript handbook (typescriptlang.org/docs/handbook/2/narrowing.html) covers narrowing patterns.