Type-safe API response handling in Typescript - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this TypeScript code with type guards?

Consider this TypeScript code that fetches user data and uses a type guard to check the response type. What will be logged to the console?

Typescript

type User = { id: number; name: string };

type ApiResponse = { status: 'success'; data: User } | { status: 'error'; message: string };

function isSuccess(response: ApiResponse): response is { status: 'success'; data: User } {
  return response.status === 'success';
}

const response: ApiResponse = { status: 'success', data: { id: 1, name: 'Alice' } };

if (isSuccess(response)) {
  console.log(`User name: ${response.data.name}`);
} else {
  console.log(`Error: ${response.message}`);
}

A Error: undefined

B TypeError at runtime

C User name: Alice

D User name: undefined

💡 Hint

Look at how the isSuccess function narrows the type of response.

The isSuccess function is a type guard that checks if response.status is 'success'. If true, TypeScript knows response has a data property with user info. So, response.data.name is 'Alice'.

🧠 Conceptual

intermediate

Which TypeScript feature ensures safe access to nested API response data?

You receive a nested API response object that may or may not have certain properties. Which TypeScript feature helps you safely access these nested properties without runtime errors?

A Type casting with angle brackets (<>)

B Non-null assertion operator (!)

C Type assertion (as keyword)

D Optional chaining operator (?.)

💡 Hint

Think about a way to safely check if a property exists before accessing it.

The optional chaining operator ?. allows you to safely access nested properties. If any part is null or undefined, it returns undefined instead of throwing an error.

🔧 Debug

advanced

What error does this TypeScript code produce when handling API response?

Examine the following code snippet. What error will TypeScript report?

Typescript

interface ApiResponse {
  status: 'ok' | 'fail';
  data?: { id: number; value: string };
  error?: string;
}

function handleResponse(response: ApiResponse) {
  if (response.status === 'ok') {
    console.log(response.data.value.toUpperCase());
  } else {
    console.error(response.error.toUpperCase());
  }
}

A Type 'string' is not assignable to type 'number' error

B Object is possibly 'undefined' error on 'response.data.value'

C No error, code compiles fine

D Property 'toUpperCase' does not exist on type 'number'

💡 Hint

Check if response.data is always defined when status is 'ok'.

The data property is optional. Even if status is 'ok', data might be undefined. Accessing response.data.value without checking causes a possible undefined error.

🚀 Application

advanced

Which code snippet correctly parses and type-checks a JSON API response?

You receive a JSON string from an API. You want to parse it and ensure it matches the ApiResponse type safely. Which snippet correctly does this with type safety?

Typescript

type ApiResponse = { status: 'success'; data: { id: number; name: string } } | { status: 'error'; message: string };

const json = '{"status":"success","data":{"id":10,"name":"Bob"}}';

A

const response = JSON.parse(json);
if (response.status === 'success' && typeof response.data?.id === 'number') {
  // safe to use response.data
}

B const response = JSON.parse(json) as ApiResponse;

C const response: ApiResponse = JSON.parse(json);

D

const response = JSON.parse(json);
console.log(response.data.name);

💡 Hint

Parsing JSON returns any. How do you check the shape before using it?

Option A parses JSON and then checks properties manually before using them. This avoids unsafe assumptions. Options A and B trust the JSON blindly, which is unsafe. Option A accesses nested data without checks, risking runtime errors.

❓ Predict Output

expert

What is the output of this TypeScript discriminated union handling code?

Given this TypeScript code that handles a discriminated union API response, what will be printed?

Typescript

type ApiResponse =
  | { type: 'text'; content: string }
  | { type: 'image'; url: string; alt: string };

function render(response: ApiResponse) {
  switch (response.type) {
    case 'text':
      return `Text: ${response.content}`;
    case 'image':
      return `Image: ${response.url} (alt: ${response.alt})`;
  }
}

const result = render({ type: 'image', url: 'http://img.com/pic.jpg', alt: 'A picture' });
console.log(result);

A Image: http://img.com/pic.jpg (alt: A picture)

B Text: undefined

C Image: undefined (alt: undefined)

D Runtime error: Property 'content' does not exist

💡 Hint

Check how the switch uses the discriminated union type property.

The render function uses response.type to narrow the union. For type === 'image', it accesses url and alt safely. So the output is the formatted string with those values.

Practice

1. What is the main benefit of using type-safe API response handling in TypeScript?

easy

A. It makes the API faster to respond.

B. It removes the need for testing API responses.

C. It automatically fixes bugs in the API.

D. It helps catch errors early by defining expected data shapes.

Solution

1. Step 1: Understand type safety purpose

   Type-safe handling means defining what data should look like before using it.

2. Step 2: Identify the benefit

   This helps catch mistakes early, like missing or wrong data types, before running the program.

3. Final Answer:

   It helps catch errors early by defining expected data shapes. -> Option D

4. Quick Check:

   Type safety = Early error detection [OK]

Hint: Type safety means catching errors before running code [OK]

Common Mistakes:

• Thinking type safety improves API speed
• Believing it fixes bugs automatically
• Assuming it replaces testing

2. Which TypeScript syntax correctly defines a generic function to fetch API data with a type-safe response?

easy

A. function fetchData(url: string): Promise<any> { /* ... */ }

B. function fetchData<T>(url: string): Promise<T> { /* ... */ }

C. function fetchData<T>(url: string): T { /* ... */ }

D. function fetchData(url: string): T { /* ... */ }

Solution

1. Step 1: Understand generic function syntax

   Generic functions use <T> to represent a type parameter, allowing flexible typing.

2. Step 2: Check return type for async fetch

   Fetching data returns a Promise of type T, so the return type must be Promise<T>.

3. Final Answer:

   function fetchData<T>(url: string): Promise<T> { /* ... */ } -> Option B

4. Quick Check:

   Generic + Promise = function fetchData<T>(url: string): Promise<T> { /* ... */ } [OK]

Hint: Generic fetch returns Promise of type T [OK]

Common Mistakes:

• Returning T directly instead of Promise<T>
• Missing generic <T> in function definition
• Using Promise<any> loses type safety

3. Given this TypeScript code, what will be the output?

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

async function getUser(): Promise<User> {
  return { id: 1, name: "Alice" };
}

getUser().then(user => console.log(user.name));

medium

A. { id: 1, name: "Alice" }

B. 1

C. "Alice"

D. undefined

Solution

1. Step 1: Analyze the getUser function

   It returns a Promise resolving to an object with id 1 and name "Alice".

2. Step 2: Check the then callback

   The callback logs user.name, which is "Alice".

3. Final Answer:

   "Alice" -> Option C

4. Quick Check:

   user.name = "Alice" [OK]

Hint: Promise resolves to object; log property name [OK]

Common Mistakes:

• Logging user instead of user.name
• Confusing id with name
• Expecting entire object printed

4. Identify the error in this TypeScript code for type-safe API response handling:

interface ApiResponse { success: boolean; data: string; }

async function fetchApi(): Promise<ApiResponse> {
  const response = await fetch('https://api.example.com');
  const json = await response.json();
  return json;
}

medium

A. Missing type assertion or validation for json before returning.

B. The fetch call should not use await.

C. The interface ApiResponse is missing a constructor.

D. The function should return void instead of Promise<ApiResponse>.

Solution

1. Step 1: Check how json is handled

   json is returned directly without confirming it matches ApiResponse shape.

2. Step 2: Understand type safety requirement

   TypeScript needs either a type assertion or runtime validation to ensure json fits ApiResponse.

3. Final Answer:

   Missing type assertion or validation for json before returning. -> Option A

4. Quick Check:

   Validate json shape before return [OK]

Hint: Always validate or assert API response type [OK]

Common Mistakes:

• Assuming fetch json is automatically typed
• Ignoring need for runtime checks
• Misunderstanding async/await usage

5. You want to create a type-safe function that fetches a list of users from an API and returns only users with an active status. Which approach correctly applies type-safe API response handling?

hard

A. Define interface User with 'active' boolean, fetch data as Promise, then filter users by active before returning.

B. Fetch data as Promise<any>, filter users by active without type checking, then cast to User[].

C. Define interface User without 'active', fetch data as Promise, then filter users by active.

D. Fetch data as Promise, return data without filtering to keep type safety.

Solution

1. Step 1: Define User interface including 'active' property

   To filter by active status, the User type must include an 'active' boolean field.

2. Step 2: Fetch data as Promise<User[]> and filter

   Fetching with correct type ensures type safety; filtering users by active keeps the result accurate and typed.

3. Final Answer:

   Define interface User with 'active' boolean, fetch data as Promise<User[]>, then filter users by active before returning. -> Option A

4. Quick Check:

   Correct interface + typed fetch + filter = Define interface User with 'active' boolean, fetch data as Promise, then filter users by active before returning. [OK]

Hint: Include all needed fields in interface before filtering [OK]

Common Mistakes:

• Casting any to User[] without checks
• Filtering on missing properties in interface
• Returning unfiltered data losing requirements