TypeScript Design Patterns for Modern Frontend Apps

TypeScript's structural type system, generics, and first-class support for interfaces and abstract classes make it unusually well-suited for applying the foundational design patterns described in Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides' 1994 book Design Patterns: Elements of Reusable Object-Oriented Software — the text that gave us the Gang of Four (GoF) patterns still in wide use today. Where JavaScript's dynamic nature made some of these patterns awkward to express, TypeScript's compile-time guarantees make them both cleaner to implement and safer to consume.

The TypeScript Handbook explicitly positions interfaces and generics as the primary mechanisms for expressing behavioral contracts in frontend code. What follows is a practical look at five patterns that map cleanly to modern TypeScript and frontend architecture, with concrete examples you can adapt immediately.

1. Factory Pattern: Centralizing Component Creation

The Factory pattern encapsulates object creation logic behind a common interface, so calling code does not need to know which concrete implementation it receives. In a React or framework-agnostic TypeScript codebase, this shows up most naturally when you need to instantiate different service implementations based on runtime configuration (e.g., a mock API client in tests, a real HTTP client in production).

interface ApiClient {
  get<T>(path: string): Promise<T>;
  post<T>(path: string, body: unknown): Promise<T>;
}

class HttpApiClient implements ApiClient {
  constructor(private baseUrl: string) {}
  async get<T>(path: string): Promise<T> { /* ... */ return {} as T; }
  async post<T>(path: string, body: unknown): Promise<T> { /* ... */ return {} as T; }
}

class MockApiClient implements ApiClient {
  async get<T>(path: string): Promise<T> { return {} as T; }
  async post<T>(path: string, body: unknown): Promise<T> { return {} as T; }
}

function createApiClient(env: 'production' | 'test'): ApiClient {
  return env === 'production'
    ? new HttpApiClient(process.env.API_BASE_URL!)
    : new MockApiClient();
}

The TypeScript interface ensures both implementations satisfy the same contract at compile time, so swapping them in tests is always safe without runtime surprises.

2. Observer Pattern: Reactive State Without a Framework

The Observer pattern defines a one-to-many dependency so that when one object changes state, all dependents are notified automatically. This is the structural backbone behind browser events, RxJS observables, React's Context + useReducer, and Zustand stores — yet implementing a lightweight, typed version yourself reveals how the pattern works and where framework abstractions save effort.

type Listener<T> = (value: T) => void;

class Store<T> {
  private listeners = new Set<Listener<T>>();
  constructor(private state: T) {}

  subscribe(listener: Listener<T>): () => void {
    this.listeners.add(listener);
    return () => this.listeners.delete(listener); // returns unsubscribe
  }

  setState(updater: (prev: T) => T): void {
    this.state = updater(this.state);
    this.listeners.forEach(l => l(this.state));
  }

  getState(): T { return this.state; }
}

Generics keep the state type strict end-to-end. The returned cleanup function from subscribe prevents memory leaks — a common source of bugs in manual Observer implementations.

3. Strategy Pattern: Swappable Algorithms at Runtime

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. In frontend work this comes up constantly when handling sorting, filtering, validation logic, or rendering approaches that vary by context without wanting a sprawling switch statement.

interface SortStrategy<T> {
  sort(items: T[]): T[];
}

class AlphaAscStrategy<T extends { name: string }> implements SortStrategy<T> {
  sort(items: T[]): T[] {
    return [...items].sort((a, b) => a.name.localeCompare(b.name));
  }
}

class DateDescStrategy<T extends { createdAt: Date }> implements SortStrategy<T> {
  sort(items: T[]): T[] {
    return [...items].sort((a, b) => b.createdAt.getTime() - a.createdAt.getTime());
  }
}

class ProductList<T extends { name: string; createdAt: Date }> {
  constructor(private items: T[], private strategy: SortStrategy<T>) {}
  setStrategy(strategy: SortStrategy<T>) { this.strategy = strategy; }
  getSorted(): T[] { return this.strategy.sort(this.items); }
}

TypeScript's generic constraints (T extends { name: string }) enforce that only compatible types can be passed to each strategy, catching mismatches at build time rather than at runtime.

4. Decorator Pattern: Wrapping Behavior Without Subclassing

The GoF Decorator pattern (distinct from TypeScript's decorator syntax, though related in spirit) adds responsibilities to an object by wrapping it in another object that shares the same interface. This is invaluable for cross-cutting concerns — logging, caching, authentication checks — that should not pollute core business logic.

class CachingApiClient implements ApiClient {
  private cache = new Map<string, unknown>();
  constructor(private inner: ApiClient) {}

  async get<T>(path: string): Promise<T> {
    if (this.cache.has(path)) return this.cache.get(path) as T;
    const result = await this.inner.get<T>(path);
    this.cache.set(path, result);
    return result;
  }

  async post<T>(path: string, body: unknown): Promise<T> {
    return this.inner.post(path, body);
  }
}

// Usage: wrap any ApiClient transparently
const client: ApiClient = new CachingApiClient(
  new HttpApiClient('https://api.example.com')
);

Because CachingApiClient implements the same ApiClient interface, calling code is entirely unaware of the caching layer. Stacking decorators (logging around caching around HTTP) follows naturally.

5. Builder Pattern: Constructing Complex Objects Step by Step

The Builder pattern separates the construction of a complex object from its representation, letting the same process produce different variants. In TypeScript frontends, query builders and form schema constructors are the most common real-world expressions of this pattern.

interface Query {
  endpoint: string;
  params: Record<string, string>;
  headers: Record<string, string>;
}

class QueryBuilder {
  private q: Query = { endpoint: '', params: {}, headers: {} };

  setEndpoint(endpoint: string): this {
    this.q = { ...this.q, endpoint };
    return this;
  }
  addParam(key: string, value: string): this {
    this.q = { ...this.q, params: { ...this.q.params, [key]: value } };
    return this;
  }
  addHeader(key: string, value: string): this {
    this.q = { ...this.q, headers: { ...this.q.headers, [key]: value } };
    return this;
  }
  build(): Readonly<Query> {
    if (!this.q.endpoint) throw new Error('Endpoint is required');
    return Object.freeze({ ...this.q });
  }
}

const query = new QueryBuilder()
  .setEndpoint('/users')
  .addParam('page', '2')
  .addHeader('Authorization', 'Bearer token')
  .build();

The immutable spread pattern inside each method ensures the builder's intermediate state is never accidentally mutated, and Readonly<Query> at build time prevents callers from modifying the result.

When Not to Use These Patterns

Pattern overuse is a real failure mode. If your codebase has a single API client that will never vary, the Factory pattern adds indirection with no return. If no one else observes a piece of state, the Observer pattern is ceremony. TypeScript's type system already enforces many invariants that pattern machinery in dynamically typed languages was originally designed to handle manually. Use patterns to solve concrete coupling and extensibility problems you have now, not hypothetical ones you might have later.

Frequently Asked Questions

Should I use TypeScript's built-in decorator syntax or the structural Decorator pattern?

They serve different purposes. TypeScript's decorator syntax (enabled with experimentalDecorators or the Stage 3 standard decorators in TypeScript 5+) modifies class declarations and members at definition time — it is metadata-driven and framework-oriented (Angular, NestJS). The structural Decorator pattern wraps instances at runtime and is framework-agnostic. For most frontend applications not using a decorator-heavy framework, the structural approach is simpler and more explicit.

How do design patterns interact with React hooks and functional patterns?

React's functional model blends pattern concepts in non-obvious ways. The custom hook (useStore, useApiClient) is often a Factory combined with Observer behavior. Context.Provider is a lightweight Service Locator. useMemo with a function dependency is a Strategy. The patterns are present — they are just expressed through hooks and closures rather than class hierarchies, which is idiomatic for modern React TypeScript development.

Do I need all five patterns for a small project?

No. For a small single-page app, most of these patterns are unnecessary overhead. Start with straightforward module-level functions and plain objects. Reach for a pattern only when a specific pain point emerges: when you find yourself duplicating object creation logic (Factory), managing multiple subscribers to shared state (Observer), or writing repeated switch statements over algorithms (Strategy). Let the problem pull the pattern in, not the other way around.

Bottom Line

We recommend learning these five patterns at the structural level before reaching for any state management library or dependency injection framework — not because libraries are bad, but because understanding the underlying patterns lets you evaluate those libraries clearly, debug them when they behave unexpectedly, and write better code around them. TypeScript makes the patterns easier to express correctly and harder to misuse than plain JavaScript, which is one of the strongest practical arguments for adopting it on any significant frontend project. Start with Observer and Factory, which solve the most common coupling problems in frontend code, and add the others as your project's complexity grows.

Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.