Discriminated union state machines in Typescript - Mini Project: Build & Apply

Discriminated Union State Machines

📖 Scenario: You are building a simple traffic light controller that changes states based on events. Each state has a unique name and specific data. Using discriminated unions helps manage these states clearly and safely.

🎯 Goal: Create a TypeScript program that defines a discriminated union type for traffic light states, writes a function to transition between states, and prints the current state.

📋 What You'll Learn

Define a discriminated union type called TrafficLightState with three states: red, yellow, and green.

Each state should have a type property with a string literal matching the state name.

Add a duration property (number) to each state representing how long the light stays in that state.

Create a variable called currentState of type TrafficLightState and initialize it to the red state with duration 30.

Write a function called nextState that takes a TrafficLightState and returns the next state in the cycle: red -> green -> yellow -> red.

Use a switch statement on the type property inside nextState to determine the next state.

Print the type and duration of the currentState after transitioning through all states once.

💡 Why This Matters

🌍 Real World

State machines are used in user interfaces, games, and hardware controllers to manage different modes or statuses clearly and safely.

💼 Career

Understanding discriminated unions and state machines is valuable for frontend and backend developers to write robust and maintainable code that handles complex state logic.

1

Define the discriminated union type and initial state

Define a discriminated union type called TrafficLightState with three states: { type: 'red', duration: number }, { type: 'yellow', duration: number }, and { type: 'green', duration: number }. Then create a variable called currentState of type TrafficLightState and set it to the red state with duration 30.

Typescript

// Define TrafficLightState type and currentState variable
// Your code here

Hint

Use a union of object types with a type property as a string literal and a duration number property.

2

Create the nextState function

Write a function called nextState that takes a parameter state of type TrafficLightState and returns a TrafficLightState. Use a switch statement on state.type to return the next state in the cycle: red goes to green with duration 60, green goes to yellow with duration 5, and yellow goes to red with duration 30.

Typescript

type TrafficLightState =
  | { type: 'red'; duration: number }
  | { type: 'yellow'; duration: number }
  | { type: 'green'; duration: number };

let currentState: TrafficLightState = { type: 'red', duration: 30 };

// Write the nextState function below
// Your code here

Hint

Use a switch on state.type and return the next state object with the correct type and duration.

3

Transition through all states once

Use the nextState function to update currentState three times, so it cycles through green, yellow, and back to red. Write three lines that assign currentState to the result of calling nextState(currentState).

Typescript

type TrafficLightState =
  | { type: 'red'; duration: number }
  | { type: 'yellow'; duration: number }
  | { type: 'green'; duration: number };

let currentState: TrafficLightState = { type: 'red', duration: 30 };

function nextState(state: TrafficLightState): TrafficLightState {
  switch (state.type) {
    case 'red':
      return { type: 'green', duration: 60 };
    case 'green':
      return { type: 'yellow', duration: 5 };
    case 'yellow':
      return { type: 'red', duration: 30 };
  }
}

// Update currentState three times using nextState
// Your code here

Hint

Call nextState(currentState) and assign it back to currentState three times.

4

Print the final state

Write a console.log statement that prints the text: Current state: TYPE, duration: DURATION where TYPE and DURATION come from the currentState properties. Use a template string with currentState.type and currentState.duration.

Typescript

type TrafficLightState =
  | { type: 'red'; duration: number }
  | { type: 'yellow'; duration: number }
  | { type: 'green'; duration: number };

let currentState: TrafficLightState = { type: 'red', duration: 30 };

function nextState(state: TrafficLightState): TrafficLightState {
  switch (state.type) {
    case 'red':
      return { type: 'green', duration: 60 };
    case 'green':
      return { type: 'yellow', duration: 5 };
    case 'yellow':
      return { type: 'red', duration: 30 };
  }
}

currentState = nextState(currentState);
currentState = nextState(currentState);
currentState = nextState(currentState);

// Print the current state and duration
// Your code here

Hint

Use console.log with a template string to show the type and duration of currentState.

Practice

1.

What is the main purpose of using a discriminated union in TypeScript state machines?

easy

A. To enable dynamic addition of states at runtime without type errors.

B. To clearly define different states with a common type property for safe type checking.

C. To allow any property names in the state objects without restrictions.

D. To automatically generate UI components based on state names.

Solution

1. Step 1: Understand discriminated unions

   Discriminated unions use a common type property to distinguish between different object shapes.

2. Step 2: Identify the purpose in state machines

   This common property allows TypeScript to safely narrow the state type and catch errors.

3. Final Answer:

   To clearly define different states with a common type property for safe type checking. -> Option B

4. Quick Check:

   Discriminated union = safe state typing [OK]

Hint: Look for the common type property in states [OK]

Common Mistakes:

• Thinking discriminated unions allow any property names freely
• Assuming states can be added dynamically without type errors
• Confusing discriminated unions with UI generation

2.

Which of the following is the correct syntax to define a discriminated union type for a state machine with states loading and success?

type State = ?

easy

A. { status: 'loading' } | { status: 'success'; data: string }

B. { type: 'loading'; data: string } | { type: 'success' }

C. { type: 'loading' } | { type: 'success'; data: string }

D. { state: 'loading' } | { state: 'success'; data: string }

Solution

1. Step 1: Identify the discriminant property

   The discriminated union requires a common property named type to distinguish states.

2. Step 2: Match the correct state shapes

   Loading state has only type: 'loading', success state has type: 'success' and extra data.

3. Final Answer:

   { type: 'loading' } | { type: 'success'; data: string } -> Option C

4. Quick Check:

   Common type property with correct fields = B [OK]

Hint: Discriminant property must be named exactly 'type' [OK]

Common Mistakes:

• Using different property names like 'status' or 'state'
• Mixing properties between states incorrectly
• Adding data to loading state incorrectly

3.

Given the following TypeScript code, what will be the output?

type State =
  | { type: 'idle' }
  | { type: 'loading' }
  | { type: 'success'; data: string };

function getMessage(state: State): string {
  switch (state.type) {
    case 'idle':
      return 'Waiting...';
    case 'loading':
      return 'Loading...';
    case 'success':
      return `Data: ${state.data}`;
  }
}

console.log(getMessage({ type: 'success', data: 'Hello' }));

medium

A. Error: Property 'data' does not exist

B. Loading...

C. Waiting...

D. Data: Hello

Solution

1. Step 1: Analyze the input state

   The input state is { type: 'success', data: 'Hello' }, matching the 'success' case.

2. Step 2: Follow the switch case logic

   For 'success', the function returns `Data: ${state.data}`, which becomes 'Data: Hello'.

3. Final Answer:

   Data: Hello -> Option D

4. Quick Check:

   State 'success' returns data string [OK]

Hint: Match type in switch to get correct output [OK]

Common Mistakes:

• Confusing 'success' with 'loading' or 'idle'
• Expecting an error accessing 'data' without checking type
• Ignoring template string interpolation

4.

Identify the error in this discriminated union state machine code:

type State =
  | { type: 'start' }
  | { type: 'end'; result: number };

function process(state: State) {
  if (state.type === 'start') {
    console.log('Starting');
  } else {
    console.log('Result is ' + state.result);
  }
}

process({ type: 'start' });

medium

A. No error; code runs and prints 'Starting'.

B. Error: Accessing 'result' on 'start' state causes runtime error.

C. Error: Missing return type annotation on function.

D. Error: 'type' property should be optional.

Solution

1. Step 1: Check the state type conditions

   The function checks if state.type === 'start' and logs 'Starting'.

2. Step 2: Confirm safe access to 'result'

   In the else branch, state.result is accessed only if state.type !== 'start', so it must be 'end' with result.

3. Final Answer:

   No error; code runs and prints 'Starting'. -> Option A

4. Quick Check:

   Type narrowing prevents invalid property access [OK]

Hint: Check type guards before accessing state-specific properties [OK]

Common Mistakes:

• Assuming accessing 'result' on 'start' state causes error
• Expecting return type annotation is mandatory
• Thinking 'type' property should be optional

5.

You want to extend a discriminated union state machine to handle an error state with an optional message. Which is the best way to define this state to keep type safety and allow missing message?

type State =
  | { type: 'idle' }
  | { type: 'loading' }
  | { type: 'success'; data: string }
  | ???

hard

A. { type: 'error'; message?: string }

B. { type: 'error'; message: string | undefined }

C. { type: 'error'; message: string }

D. { type: 'error'; message: string | null }

Solution

1. Step 1: Understand optional properties in discriminated unions

   Using message?: string means the property can be missing or a string, which fits optional message.

2. Step 2: Compare other options

   { type: 'error'; message: string | undefined } requires the property but allows undefined explicitly, less idiomatic. { type: 'error'; message: string } requires message always. { type: 'error'; message: string | null } requires message but allows null, which is less type safe.

3. Final Answer:

   { type: 'error'; message?: string } -> Option A

4. Quick Check:

   Optional property syntax keeps type safety and flexibility [OK]

Hint: Use '?' to mark optional properties in state types [OK]

Common Mistakes:

• Making message required when it should be optional
• Using union with undefined instead of optional property
• Allowing null which can cause runtime issues