Type-safe builder pattern in Typescript - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main goal of the type-safe builder pattern?

To ensure that objects are built step-by-step with compile-time checks, preventing incomplete or invalid object creation.

intermediate

How does TypeScript help enforce the type-safe builder pattern?

By using generics and conditional types to track which properties have been set, TypeScript can prevent calling build() before all required fields are provided.

beginner

In a type-safe builder, what happens if you try to build an object without setting all required fields?

The TypeScript compiler will show an error, stopping you from building an incomplete object.

beginner

Why use a builder pattern instead of a simple constructor?

Because the builder pattern allows setting properties step-by-step with clear method calls, improving readability and flexibility, especially for complex objects.

advanced

What TypeScript feature is commonly used to track which builder steps are completed?

Mapped types and conditional types are used to track the state of the builder, marking which properties are set and which are still missing.

What does the type-safe builder pattern prevent?

A Creating objects with missing required properties

B Using classes in TypeScript

C Writing functions without return types

D Declaring variables without types

The type-safe builder pattern ensures all required properties are set before building the object.

Which TypeScript feature helps track builder state in a type-safe builder?

A Generics and conditional types

B Enums

C Type assertions

D Namespaces

Generics and conditional types allow tracking which properties are set during the build process.

What happens if you call build() too early in a type-safe builder?

A Nothing, it works fine

B The program crashes at runtime

C The object is built with default values

D TypeScript compiler shows an error

The compiler prevents building incomplete objects by showing an error.

Why is the builder pattern useful for complex objects?

A It automatically generates getters and setters

B It makes objects immutable

C It allows setting properties step-by-step clearly

D It replaces constructors with functions

Step-by-step setting improves readability and flexibility for complex object creation.

Which of these is NOT a benefit of the type-safe builder pattern?

A Compile-time safety for object creation

B Automatically optimizes performance

C Improves code readability

D Prevents runtime errors from missing fields

The builder pattern focuses on safety and readability, not performance optimization.

Explain how TypeScript generics and conditional types help implement a type-safe builder pattern.

Think about how the builder knows which properties are set.

Describe the advantages of using a type-safe builder pattern over a simple constructor function.

Consider readability and safety benefits.

Practice

1.

What is the main benefit of using a type-safe builder pattern in TypeScript?

easy

A. It ensures all required properties are set before creating the object.

B. It makes the code run faster at runtime.

C. It automatically generates UI forms.

D. It removes the need for interfaces.

Solution

1. Step 1: Understand the purpose of type-safe builder pattern

   The pattern helps build objects step-by-step while ensuring correctness.

2. Step 2: Identify the key benefit

   It uses TypeScript's type system to check that all required properties are set before final object creation.

3. Final Answer:

   It ensures all required properties are set before creating the object. -> Option A

4. Quick Check:

   Type safety = required properties checked [OK]

Hint: Remember: type-safe means catching errors before running [OK]

Common Mistakes:

• Thinking it improves runtime speed
• Confusing it with UI generation
• Assuming it removes interfaces

2.

Which of the following is the correct way to declare a generic builder class in TypeScript?

class Builder<T> {
  private data: T;
  constructor() {
    this.data = {} as T;
  }
  build(): T {
    return this.data;
  }
}

easy

A. class Builder<T> { private data: T; constructor() { this.data = undefined; } build(): T { return this.data; } }

B. class Builder { private data: any; constructor() { this.data = {}; } build(): any { return this.data; } }

C. class Builder<T> { private data: T; constructor() { this.data = {} as T; } build(): T { return this.data; } }

D. class Builder<T> { private data: T; constructor() { this.data = null; } build(): T { return this.data; } }

Solution

1. Step 1: Check generic class declaration

   class Builder<T> { private data: T; constructor() { this.data = {} as T; } build(): T { return this.data; } } correctly declares a generic class with <T> and initializes data as {} as T.

2. Step 2: Verify build method return type

   The build() method returns data typed as T, matching the generic type.

3. Final Answer:

   class Builder<T> { private data: T; constructor() { this.data = {} as T; } build(): T { return this.data; } } -> Option C

4. Quick Check:

   Generic class with typed data = class Builder<T> { private data: T; constructor() { this.data = {} as T; } build(): T { return this.data; } } [OK]

Hint: Look for generic <T> and proper initialization [OK]

Common Mistakes:

• Using any instead of generic type
• Initializing data with null or undefined
• Missing generic parameter in class

3.

Consider this TypeScript code using a type-safe builder pattern:

interface User {
  name: string;
  age: number;
}

class UserBuilder {
  private user = {} as Partial<User>;
  setName(name: string) { this.user.name = name; return this; }
  setAge(age: number) { this.user.age = age; return this; }
  build(): User {
    if (!this.user.name || !this.user.age) throw new Error('Missing fields');
    return this.user as User;
  }
}

const user = new UserBuilder().setName('Alice').setAge(30).build();
console.log(user);

What will be the output?

medium

A. { name: 'Alice', age: 30 }

B. Error: Missing fields

C. undefined

D. { name: 'Alice' }

Solution

1. Step 1: Trace method calls on UserBuilder

   The builder sets name to 'Alice' and age to 30, so both required fields are set.

2. Step 2: Check build method behavior

   Since both fields exist, no error is thrown, and the object is returned as User.

3. Final Answer:

   { name: 'Alice', age: 30 } -> Option A

4. Quick Check:

   All fields set = object returned [OK]

Hint: Check if all required fields are set before build [OK]

Common Mistakes:

• Assuming error thrown even when fields set
• Expecting undefined output
• Missing age property in output

4.

Identify the error in this type-safe builder pattern code and select the fix:

interface Car {
  make: string;
  year: number;
}

class CarBuilder {
  private car = {} as Partial<Car>;
  setMake(make: string) { this.car.make = make; return this; }
  setYear(year: number) { this.car.year = year; return this; }
  build(): Car {
    if (!this.car.make || !this.car.year) throw new Error('Missing fields');
    return this.car;
  }
}

medium

A. Initialize car as Car instead of Partial<Car>

B. Change return type of build() to Partial<Car>

C. Remove the if check for missing fields

D. Cast return value as Car: return this.car as Car;

Solution

1. Step 1: Identify the type mismatch in build()

   The method returns this.car which is typed as Partial<Car>, but the return type is Car.

2. Step 2: Fix by casting to Car

   To satisfy the return type, cast this.car as Car after checking required fields.

3. Final Answer:

   Cast return value as Car: return this.car as Car; -> Option D

4. Quick Check:

   Return type must match method signature [OK]

Hint: Cast partial object to full type after validation [OK]

Common Mistakes:

• Changing return type to Partial<Car>
• Removing validation checks
• Initializing with full Car without setting fields

5.

You want to create a type-safe builder for a Product with required id and name, and optional description. Which approach best enforces setting required fields before build?

interface Product {
  id: number;
  name: string;
  description?: string;
}

// Which builder pattern enforces required fields at compile time?

hard

A. Use a single class with optional properties and runtime checks in build()

B. Use generics with flags tracking set fields and conditional types for build()

C. Use a function that returns a partial Product object without checks

D. Use inheritance to extend a base builder class without generics

Solution

1. Step 1: Understand compile-time enforcement

   Only generics with flags and conditional types can enforce required fields before build at compile time.

2. Step 2: Compare options

   Use generics with flags tracking set fields and conditional types for build() uses TypeScript generics and conditional types to track which fields are set, preventing build() call until required fields are set.

3. Final Answer:

   Use generics with flags tracking set fields and conditional types for build() -> Option B

4. Quick Check:

   Compile-time safety = generics + conditional types [OK]

Hint: Use generics and conditional types to enforce required fields [OK]

Common Mistakes:

• Relying only on runtime checks
• Using inheritance without generics
• Returning partial objects without enforcement