Control flow analysis behavior in Typescript - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Control flow narrowing with type guards

What is the output of this TypeScript code when calling processValue(42)?

Typescript

function processValue(value: string | number) {
  if (typeof value === 'string') {
    return value.toUpperCase();
  } else {
    return value.toFixed(2);
  }
}

console.log(processValue(42));

A "42.0"

B "42"

C "42.00"

D TypeError at runtime

💡 Hint

Think about how TypeScript narrows the type inside the if-else blocks.

The function narrows the type of 'value' using 'typeof'. For a number input, it calls 'toFixed(2)', which formats the number with two decimals, returning the string "42.00".

❓ Predict Output

intermediate

Control flow with union types and null checks

What will be logged when running this TypeScript code?

Typescript

function greet(name: string | null) {
  if (name) {
    console.log(`Hello, ${name.toUpperCase()}!`);
  } else {
    console.log("Hello, guest!");
  }
}

greet(null);

A Hello, null!

B Hello, NULL!

C TypeError: Cannot read property 'toUpperCase' of null

D Hello, guest!

💡 Hint

Check how the if condition treats null values.

The if condition treats null as falsy, so the else branch runs, logging "Hello, guest!".

❓ Predict Output

advanced

Control flow with discriminated unions and exhaustive checks

What is the output of this TypeScript code?

Typescript

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; size: number };

function area(shape: Shape) {
  switch (shape.kind) {
    case "circle":
      return Math.PI * shape.radius ** 2;
    case "square":
      return shape.size ** 2;
  }
}

console.log(area({ kind: "circle", radius: 3 }));

A 28.274333882308138

B 9

C undefined

D TypeError at runtime

💡 Hint

Recall the formula for the area of a circle and how discriminated unions work.

The function calculates the area of a circle with radius 3 using πr², which is approximately 28.2743.

❓ Predict Output

advanced

Control flow with type narrowing and assignment

What will be the value of result after running this TypeScript code?

Typescript

let input: string | number = "hello";

if (typeof input === "string") {
  input = input.length;
}

const result = input;

A TypeError at runtime

B 5

C "hello"

D undefined

💡 Hint

Check how the variable 'input' is reassigned inside the if block.

Initially, 'input' is a string. Inside the if block, it is reassigned to the string's length (a number). So 'result' is 5.

❓ Predict Output

expert

Control flow with type predicates and custom type guards

What is the output of this TypeScript code?

Typescript

interface Fish {
  swim(): void;
}

interface Bird {
  fly(): void;
}

function isFish(pet: Fish | Bird): pet is Fish {
  return (pet as Fish).swim !== undefined;
}

function move(pet: Fish | Bird) {
  if (isFish(pet)) {
    return "Fish swims";
  } else {
    return "Bird flies";
  }
}

console.log(move({ fly() { console.log('flying'); } }));

A "Bird flies"

B "Fish swims"

C TypeError at runtime

D undefined

💡 Hint

Understand how the custom type guard function works.

The object has a 'fly' method but no 'swim' method, so 'isFish' returns false, and the else branch returns "Bird flies".

Practice

1.

What does TypeScript's control flow analysis primarily help with?

easy

A. Running the program faster by optimizing loops

B. Tracking variable types through code paths to catch errors early

C. Automatically fixing syntax errors in the code

D. Converting TypeScript code into JavaScript

Solution

1. Step 1: Understand control flow analysis purpose

   Control flow analysis tracks how variables change types through different code paths.

2. Step 2: Identify its main benefit

   This helps TypeScript catch type errors before running the program.

3. Final Answer:

   Tracking variable types through code paths to catch errors early -> Option B

4. Quick Check:

   Control flow analysis = type tracking [OK]

Hint: Control flow = tracking variable types in code paths [OK]

Common Mistakes:

• Confusing control flow analysis with code execution speed
• Thinking it fixes syntax errors automatically
• Believing it compiles TypeScript to JavaScript

2.

Which of the following TypeScript code snippets correctly narrows a variable's type using control flow analysis?

let value: string | number = 5;
if (typeof value === 'string') {
  console.log(value.toUpperCase());
}

easy

A. The code should use instanceof instead of typeof

B. The code will cause a runtime error because value can be a number

C. The code needs a type assertion to call toUpperCase()

D. The code is correct and safe to call toUpperCase() inside the if block

Solution

1. Step 1: Check the type guard condition

   The condition typeof value === 'string' narrows value to string inside the if block.

2. Step 2: Confirm safe method call

   Since value is string here, calling toUpperCase() is safe and valid.

3. Final Answer:

   The code is correct and safe to call toUpperCase() inside the if block -> Option D

4. Quick Check:

   Type guard narrows type = safe method call [OK]

Hint: Use typeof checks to narrow union types safely [OK]

Common Mistakes:

• Calling string methods without type narrowing
• Confusing typeof with instanceof for primitives
• Assuming type assertions are always needed

3.

What will be the output of this TypeScript code?

function checkValue(x: string | number) {
  if (typeof x === 'number') {
    return x.toFixed(2);
  } else {
    return x.toUpperCase();
  }
}
console.log(checkValue('hello'));
console.log(checkValue(3.14159));

medium

A. Runtime error because toFixed is not a function

B. "hello" and "3.14159"

C. "HELLO" and "3.14"

D. "HELLO" and "3.14159"

Solution

1. Step 1: Analyze the first call with string

   For 'hello', the else block runs, returning 'HELLO' after toUpperCase().

2. Step 2: Analyze the second call with number

   For 3.14159, the if block runs, returning '3.14' after toFixed(2).

3. Final Answer:

   "HELLO" and "3.14" -> Option C

4. Quick Check:

   Type guards produce correct string outputs [OK]

Hint: Check typeof to predict which block runs [OK]

Common Mistakes:

• Assuming toFixed returns a number, not string
• Ignoring type narrowing in if-else
• Mixing up output formatting

4.

Identify the error in this TypeScript code related to control flow analysis:

function process(input: string | null) {
  if (input) {
    console.log(input.toLowerCase());
  } else {
    console.log(input.toLowerCase());
  }
}

medium

A. Calling toLowerCase() on null in the else block causes a runtime error

B. The if condition should be input !== null instead of input

C. TypeScript will automatically fix this error during compilation

D. There is no error; the code is safe

Solution

1. Step 1: Check the else block usage

   In the else block, input is null, so calling toLowerCase() causes a runtime error.

2. Step 2: Understand control flow limitation

   Control flow analysis narrows input in the if block but not in else, so unsafe call happens.

3. Final Answer:

   Calling toLowerCase() on null in the else block causes a runtime error -> Option A

4. Quick Check:

   Null check needed before method call [OK]

Hint: Else block may have null; avoid method calls there [OK]

Common Mistakes:

• Assuming if(input) excludes null everywhere
• Expecting TypeScript to fix runtime errors
• Using loose null checks without safe calls

5.

Given this TypeScript code, what is the best way to fix the control flow analysis issue to avoid errors?

function formatInput(input: string | number | null) {
  if (typeof input === 'string') {
    return input.trim();
  } else if (typeof input === 'number') {
    return input.toFixed(1);
  }
  return input.trim();
}

hard

A. Add a null check before the last return to avoid calling trim() on null

B. Remove the last return statement because it's unreachable

C. Change all trim() calls to toString()

D. Use a type assertion to force input as string in the last return

Solution

1. Step 1: Identify the problem with last return

   The last return input.trim() runs when input is null, causing an error.

2. Step 2: Fix by adding null check

   Adding a check like if (input !== null) before calling trim() prevents errors.

3. Final Answer:

   Add a null check before the last return to avoid calling trim() on null -> Option A

4. Quick Check:

   Null checks prevent unsafe method calls [OK]

Hint: Always check for null before calling methods on unions [OK]

Common Mistakes:

• Ignoring null possibility in union types
• Assuming last return is unreachable
• Using type assertions without safety