TypeScript Types You’ll Actually Use (Not the Flex Ones)

Quickstart

Want immediate value? Do these in order. Each step is small, but together they upgrade your entire codebase: better autocomplete, fewer runtime surprises, and refactors that don’t feel like defusing a bomb.

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "useUnknownInCatchVariables": true
  }
}

Overview

TypeScript isn’t about adding types everywhere. It’s about adding useful constraints so your editor and compiler can do real work: prevent invalid states, guide refactors, and make APIs self-documenting.

This post intentionally skips the “flex” side: overly clever conditional types, deep type-level programming, and patterns that make teammates squint. Those can be powerful, but most teams get more value from clear models and good boundaries.

Core concepts

Think of TypeScript as a design tool for your program’s shapes and states. These core concepts are the ones you’ll reuse across React apps, Node APIs, shared libraries, and even quick scripts.

1) Types belong at boundaries

Boundaries are where uncertainty enters: network responses, user input, database reads, environment variables, and third-party libraries. Once data is validated and shaped, let inference carry you.

2) Unions & literals: express “either/or” clearly

Unions are the workhorse of practical TypeScript. Combine them with literal types (string/number literals) to encode valid values and eliminate entire classes of runtime checks.

3) unknown vs any: the “trust boundary” rule

If data comes from outside your code (API, JSON, user input), start with unknown. It forces you to narrow and validate. any turns off the compiler exactly where you need it most.

4) Interface vs type alias (a simple rule)

Both are great. Pick one convention and keep it consistent. If you need a rule that works well in real teams:

5) Utility types are your “type power tools”

Utility types keep your code DRY and aligned. Instead of defining multiple similar shapes, define one canonical model and derive “views” for specific use cases (create payload, update payload, list view, etc.).

Step-by-step

Let’s build a small but realistic “types first” setup you can copy into a codebase. The goal: fewer bugs, better autocomplete, and predictable refactors—without doing anything fancy.

Step 1 — Make the compiler work for you

Turn on strictness early. If you’re migrating a JS project, enable strict mode gradually (folder by folder), but keep a clear end goal: a codebase where new code is strictly typed and old code is being paid down intentionally.

Step 2 — Define one canonical domain model

Pick the “center” type once (the thing you store and reason about) and derive variations from it. This is where Pick and Omit shine: you stop duplicating shapes and keep everything consistent as requirements change.

Step 3 — Encode UI/API states as discriminated unions

This is one of the highest ROI TypeScript patterns. Instead of juggling isLoading, error, and data, represent each state as its own shape. The compiler will make sure you handle them all.

type ApiError = {
  message: string;
  code?: "UNAUTHORIZED" | "NOT_FOUND" | "RATE_LIMIT";
};

type LoadState<T> =
  | { kind: "idle" }
  | { kind: "loading" }
  | { kind: "success"; data: T }
  | { kind: "error"; error: ApiError };

function assertNever(x: never): never {
  throw new Error("Unhandled case: " + JSON.stringify(x));
}

function renderUser(state: LoadState<{ id: string; name: string }>) {
  switch (state.kind) {
    case "idle":
      return "Click to load";
    case "loading":
      return "Loading…";
    case "success":
      return `Hello, ${state.data.name}`;
    case "error":
      return `Oops: ${state.error.message}`;
    default:
      return assertNever(state);
  }
}

Step 4 — Derive “payload” types with utility types

Real apps rarely send/receive the exact same shape you store. Use utility types to define those differences explicitly and keep them in sync with the canonical type.

Step 5 — Use satisfies and as const to keep config safe

Config objects are where bugs hide: typos in keys, missing cases, or values that drift from what the code expects. Two modern patterns help a lot:

• as const preserves literal types (so you don’t accidentally widen to string).
• satisfies checks a shape without losing specific literal information.

type Role = "guest" | "member" | "admin";

type RouteGuard = {
  requiresAuth: boolean;
  allowed: Role[];
};

const guards = {
  "/": { requiresAuth: false, allowed: ["guest", "member", "admin"] },
  "/account": { requiresAuth: true, allowed: ["member", "admin"] },
  "/admin": { requiresAuth: true, allowed: ["admin"] }
} satisfies Record<string, RouteGuard>;

// guards["/admni"] would still be a runtime bug, but:
// - typos in the object shape are caught
// - values must match Role[]
// - you keep useful literal info for autocomplete

Step 6 — Learn narrowing (it’s the daily driver)

Most real-world TypeScript work is narrowing: turning “maybe” into “definitely” using checks the compiler understands. You’ll use this constantly with union types, optional properties, and unknown data.

Common mistakes

TypeScript pain is usually self-inflicted. These are the most common pitfalls that make TS feel “busy” or “fragile”, and the fixes that keep your types practical.

FAQ

Should I use type or interface in TypeScript?

Use whichever your team standardizes on, but reach for type when you need unions and compositions. Use interface when you’re defining a public object shape that might be extended or merged. Consistency matters more than the “perfect” choice.

What TypeScript types give the biggest day-to-day value?

Unions (especially discriminated unions), literal types, and utility types like Pick/Omit/Record. These reduce duplication, prevent impossible states, and make refactors safer with minimal overhead.

When should I use unknown instead of any?

Use unknown for any external input you haven’t validated. It forces narrowing and prevents accidental property access. Reserve any for rare cases (like integrating untyped libraries) and isolate it behind wrappers.

Is as casting always bad?

No—casts are fine when you’re adding information the compiler can’t infer, after validation. They’re risky when used to skip validation (e.g., casting API JSON directly to a domain model). Prefer narrowing functions and parsers at the boundaries.

Why does TypeScript still let runtime bugs happen?

TypeScript checks types at compile time, not runtime. If you lie to the compiler (casts) or accept unvalidated external data, runtime can still break. The fix is to validate at boundaries and keep internal types trustworthy.

What’s the best way to type API responses?

Define response DTO types and keep domain models separate when needed. Treat API data as untrusted until validated/normalized, then convert into your internal model. This prevents “API drift” from silently corrupting core logic.

Cheatsheet

A fast scan you can bookmark. These are the TypeScript types you’ll actually use most weeks.

Wrap-up

Practical TypeScript is not about showing off. It’s about making your codebase easier to change without fear. If you take only a few things from this post:

• Type the boundaries (external input, public APIs), then let inference handle the rest.
• Use unions (especially discriminated unions) to model state and eliminate impossible combinations.
• Derive types with utility types instead of copying shapes across layers.
• Avoid “turning off the compiler” with any and unvalidated casts.

Keep this page bookmarked. The cheatsheet + the state-union pattern will pay for themselves the next time you do a refactor under pressure.

Related posts

• Python Dataclasses: Cleaner Models With Less Boilerplate
• Python in 60 Minutes: From Zero to Useful
• Top 25 Python Errors (And the 1-Line Fixes)
• Make Python Faster: 12 Micro-Optimizations That Matter
• Asyncio Explained With 3 Real Projects
• Publish a Python Package the Right Way (pyproject.toml + CI)