Best Practices

Pattern 1: API Response Modeling

type ApiResponse<T> =
    | { status: "success"; data: T }
    | { status: "error"; message: string };

Why this pattern is strong:

explicit success and error shapes
easy narrowing by status
safer API handling in UI and services

Pattern 2: Exhaustive Reducers

type Action =
    | { type: "increment"; amount: number }
    | { type: "decrement"; amount: number };

function reducer(state: number, action: Action): number {
    switch (action.type) {
        case "increment":
            return state + action.amount;
        case "decrement":
            return state - action.amount;
        default: {
            const _never: never = action;
            return _never;
        }
    }
}

This prevents silent bugs when new actions are introduced.

Pattern 3: Strong Domain Types

Instead of generic names like string, create clear domain aliases.

type UserId = string;
type Email = string;

interface User {
    id: UserId;
    email: Email;
}

This improves readability and intent.

Pattern 4: Avoid `any`, Prefer Narrow Contracts

function parseJson(input: string): unknown {
    return JSON.parse(input);
}

Then validate shape before use.

Team-Level Standards

Keep strict mode on

Never disable strict checks globally to “quickly fix” errors.

Prefer explicit API contracts

Types for requests, responses, and shared models should be clear and centralized.

Use reusable type utilities

Avoid copy-pasting similar type definitions across files.

Write readable types

Clever one-line types are less valuable than clear maintainable ones.

Interview Answer Framework

When asked “How do you design TypeScript for scale?”, answer in this structure:

Start with strict tsconfig and linting standards.
Model domain objects using interfaces and type aliases.
Use unions and discriminators for state and API flows.
Apply generics for reusable infrastructure.
Use utility, mapped, and conditional types when duplication appears.
Add exhaustiveness checks to prevent unhandled cases.
Use runtime validation for external input.

End-to-End Picture

graph LR A[Domain Model Types] --> B[Service Layer] B --> C[UI or API Handlers] C --> D[Discriminated State] D --> E[Exhaustive Handling] E --> F[Safe Refactoring Over Time]