TypeScript Patterns That Actually Scale

If your app has a loading spinner, an error banner, and a success state, you have a state machine. You might be modeling it with a bag of optional fields and praying. That’s like using a grocery list as a contract. Technically words on paper, legally meaningless.

Discriminated unions fix this:

// The "bag of maybes" approach — invites impossible states
type User = {
  status: string;
  name?: string;
  error?: string;
  loadedAt?: Date;
};

// Discriminated unions — each state is explicit
type User =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "loaded"; name: string; loadedAt: Date }
  | { status: "error"; error: string };

Now TypeScript actually earns its keep. It forces you to handle every case, and it narrows the type in each branch:

function renderUser(user: User) {
  switch (user.status) {
    case "idle":
      return "Click to load user";
    case "loading":
      return "Loading...";
    case "loaded":
      // TypeScript knows `name` and `loadedAt` exist here
      return `${user.name} (loaded ${user.loadedAt.toLocaleDateString()})`;
    case "error":
      // TypeScript knows `error` exists here
      return `Failed: ${user.error}`;
  }
}

Here’s a fun one. TypeScript will happily let you pass a userId where an orderId is expected, because they’re both string. It’s like a librarian who files books alphabetically by color. Technically organized, functionally useless.

Branded types add a phantom tag to primitives so the compiler can tell them apart:

type Brand<T, B extends string> = T & { __brand: B };

type UserId = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;
type Email = Brand<string, "Email">;

// Constructor functions with validation
function UserId(id: string): UserId {
  if (!id.startsWith("usr_")) throw new Error("Invalid user ID");
  return id as UserId;
}

function Email(email: string): Email {
  if (!email.includes("@")) throw new Error("Invalid email");
  return email as Email;
}

Now swapping arguments is a compile-time error instead of a 2 AM production incident:

function getOrder(userId: UserId, orderId: OrderId) {
  // ...
}

const uid = UserId("usr_abc123");
const oid = "ord_xyz789" as OrderId;

getOrder(uid, oid);   // OK
getOrder(oid, uid);   // Error: Argument of type 'OrderId' is not assignable to 'UserId'

By default, TypeScript widens your constants into general types. Define timeout: 5000 and TypeScript sees number. Thanks for nothing.

The as const assertion locks everything down to exact literal types, deeply readonly:

// Without as const — types are widened
const CONFIG = {
  api: "https://api.example.com",
  timeout: 5000,
  retries: 3,
};
// Type: { api: string; timeout: number; retries: number }

// With as const — exact literal types, deeply readonly
const CONFIG = {
  api: "https://api.example.com",
  timeout: 5000,
  retries: 3,
} as const;
// Type: { readonly api: "https://api.example.com"; readonly timeout: 5000; readonly retries: 3 }

Where this really pays off is deriving union types from runtime values, single source of truth, no duplication:

const ROLES = ["admin", "editor", "viewer"] as const;
type Role = (typeof ROLES)[number]; // "admin" | "editor" | "viewer"

const STATUS_MAP = {
  active: { label: "Active", color: "green" },
  inactive: { label: "Inactive", color: "gray" },
  banned: { label: "Banned", color: "red" },
} as const;

type Status = keyof typeof STATUS_MAP; // "active" | "inactive" | "banned"

Add a new role to the array and the Role type updates automatically. Remove one and every usage lights up red. It’s the kind of thing that makes you wonder why you ever maintained types and values separately.

I genuinely think satisfies is the most underused feature in modern TypeScript. It solves the ancient tension between “I want the compiler to validate this” and “I want to keep my nice narrow types.” Before satisfies, you had to pick one.

type Theme = {
  colors: Record<string, string>;
  spacing: Record<string, number>;
};

// With a type annotation — validates, but you lose specificity
const theme: Theme = {
  colors: { primary: "#d4a96a", bg: "#1a1209" },
  spacing: { sm: 4, md: 8, lg: 16 },
};
theme.colors.primary; // string (we lost the literal)
theme.colors.oops;    // string (no error — Record<string, string> allows any key)

// With satisfies — validates AND preserves narrow types
const theme = {
  colors: { primary: "#d4a96a", bg: "#1a1209" },
  spacing: { sm: 4, md: 8, lg: 16 },
} satisfies Theme;
theme.colors.primary; // "#d4a96a" (literal preserved)
theme.colors.oops;    // Error: Property 'oops' does not exist

I reach for satisfies on config objects, route definitions, and anywhere I want validation without surrendering type precision:

type RouteConfig = {
  path: string;
  auth: boolean;
  roles?: readonly string[];
};

const routes = {
  home: { path: "/", auth: false },
  dashboard: { path: "/dashboard", auth: true, roles: ["admin", "editor"] as const },
  settings: { path: "/settings", auth: true },
} satisfies Record<string, RouteConfig>;

// Full autocompletion on routes.dashboard.roles
// TypeScript knows it's readonly ["admin", "editor"], not string[] | undefined

Template literal types let you enforce string patterns without a runtime regex. It’s like having a bouncer at the door of your function signatures:

type HttpMethod = "GET" | "POST" | "PUT" | "DELETE";
type ApiPath = `/${string}`;
type Endpoint = `${HttpMethod} ${ApiPath}`;

function registerRoute(endpoint: Endpoint, handler: () => void) {
  // ...
}

registerRoute("GET /users", listUsers);       // OK
registerRoute("POST /users", createUser);      // OK
registerRoute("PATCH /users", updateUser);     // Error: not a valid HttpMethod
registerRoute("GET users", listUsers);         // Error: path must start with /

Combine them with mapped types and things get interesting:

type EventMap = {
  click: { x: number; y: number };
  keydown: { key: string; code: string };
  scroll: { offset: number };
};

type EventHandler<T extends keyof EventMap> = (event: EventMap[T]) => void;

type PrefixedHandlers = {
  [K in keyof EventMap as `on${Capitalize<K>}`]: EventHandler<K>;
};

// PrefixedHandlers = {
//   onClick: (event: { x: number; y: number }) => void;
//   onKeydown: (event: { key: string; code: string }) => void;
//   onScroll: (event: { offset: number }) => void;
// }

TypeScript ships decent utility types out of the box, but the real leverage comes from composing them. Here are three I’ve copy-pasted into enough projects that they deserve a permanent home:

// Make specific fields required (rest stay as-is)
type RequireFields<T, K extends keyof T> = T & Required<Pick<T, K>>;

type User = {
  id: string;
  name?: string;
  email?: string;
  avatar?: string;
};

type UserWithEmail = RequireFields<User, "email">;
// { id: string; name?: string; email: string; avatar?: string }

// Deep partial — makes every nested field optional
type DeepPartial<T> = {
  [P in keyof T]?: T[P] extends object ? DeepPartial<T[P]> : T[P];
};

type Settings = {
  display: { theme: string; fontSize: number };
  notifications: { email: boolean; push: boolean };
};

type SettingsUpdate = DeepPartial<Settings>;
// Can pass { display: { fontSize: 14 } } without specifying theme

// Extract function parameter types as a named tuple
type Params<T extends (...args: any[]) => any> = T extends (...args: infer P) => any ? P : never;

function createUser(name: string, email: string, role: "admin" | "user") {
  // ...
}

type CreateUserParams = Params<typeof createUser>;
// [name: string, email: string, role: "admin" | "user"]

When constructing complex objects, a typed builder gives you autocompletion, validation, and the satisfying feeling of chaining methods like train cars clicking together:

type QueryConfig = {
  table: string;
  columns: string[];
  where?: string;
  orderBy?: string;
  limit?: number;
};

class QueryBuilder<T extends Partial<QueryConfig> = {}> {
  private config: T;

  constructor(config: T = {} as T) {
    this.config = config;
  }

  from<Table extends string>(table: Table) {
    return new QueryBuilder({ ...this.config, table });
  }

  select<Cols extends string[]>(...columns: Cols) {
    return new QueryBuilder({ ...this.config, columns });
  }

  where(condition: string) {
    return new QueryBuilder({ ...this.config, where: condition });
  }

  limit(n: number) {
    return new QueryBuilder({ ...this.config, limit: n });
  }

  build(this: QueryBuilder<QueryConfig>): QueryConfig {
    return this.config;
  }
}

const query = new QueryBuilder()
  .from("users")
  .select("id", "name", "email")
  .where("active = true")
  .limit(10)
  .build(); // Only callable when all required fields are set

The trick here is the this parameter on build(). It won’t compile unless you’ve set table and columns. Try calling .build() without .from() and TypeScript slaps your hand. Beautiful.

These patterns are tools, not commandments. Here’s my mental shortcut:

The goal isn’t to flex every advanced feature TypeScript offers. It’s to make impossible states impossible and let the compiler catch mistakes before your users do. Start with discriminated unions and satisfies. They deliver the biggest payoff with the least brain damage. Layer on the rest as your codebase demands it. Having the right editor tooling helps too. I cover TypeScript-specific extensions in my VS Code extensions guide.