Enum vs union literal type trade-offs in Typescript - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of enum vs union literal type usage

What is the output of this TypeScript code when compiled to JavaScript and run?

Typescript

enum Direction {
  Up = "UP",
  Down = "DOWN"
}

function move(dir: Direction | "LEFT" | "RIGHT") {
  switch (dir) {
    case Direction.Up:
      return "Moving up";
    case Direction.Down:
      return "Moving down";
    case "LEFT":
      return "Moving left";
    case "RIGHT":
      return "Moving right";
  }
}

console.log(move(Direction.Up));
console.log(move("LEFT"));

A

"Moving up"
"Moving left"

B

"Moving Up"
"Moving Left"

C TypeError at runtime

D

undefined
undefined

💡 Hint

Check how enum values and union literal strings are compared in the switch.

The enum Direction has string values "UP" and "DOWN". The function move accepts either Direction enum or union literals "LEFT" or "RIGHT". The switch matches the exact string values, so Direction.Up is "UP" which matches case Direction.Up and returns "Moving up". The string "LEFT" matches case "LEFT" and returns "Moving left".

🧠 Conceptual

intermediate

Trade-off: Enum vs Union Literal Types for Type Safety

Which statement best describes a key trade-off between using enums and union literal types in TypeScript?

A Enums cannot be used in switch statements, but union literals can.

B Enums provide runtime objects and can be iterated, but union literals offer better type narrowing and simpler code.

C Union literals create runtime objects, while enums exist only at compile time.

D Union literals allow adding new values at runtime, enums do not.

💡 Hint

Think about what exists at runtime and how TypeScript narrows types.

Enums compile to real JavaScript objects, so you can iterate over them or access their values at runtime. Union literal types exist only at compile time and provide better type narrowing and simpler syntax but no runtime representation.

🔧 Debug

advanced

Why does this enum code cause a runtime error?

Consider this TypeScript code snippet: ```typescript enum Status { Active, Inactive, Pending } function checkStatus(s: Status) { if (s === Status.Pending) { console.log("Pending status"); } } checkStatus(3); ``` What is the cause of the runtime error?

A The function checkStatus is missing a return statement.

B Enums cannot be compared with === operator.

C The enum values are numeric and 3 is not a valid Status value, causing undefined behavior.

D The enum Status is not exported, causing a reference error.

💡 Hint

Check the numeric values assigned to enum members and what happens when you pass 3.

The enum Status assigns Active=0 (default), Inactive=1, Pending=2. Passing 3 is allowed because numeric enums accept any number, but 3 does not correspond to a defined enum member value (Status.Pending is 2), so the comparison fails and it can cause logic errors or undefined behavior if invalid values are not handled.

📝 Syntax

advanced

Which option causes a syntax error in union literal type declaration?

Which of the following union literal type declarations is invalid TypeScript syntax?

A type Directions = Up | Down | Left | Right;

B type Colors = "red" | "green" | "blue";

C type Sizes = 'small' | 'medium' | 'large';

D type Status = "active" | "inactive" | "pending";

💡 Hint

Check if the literals are quoted strings or identifiers.

Union literal types must be string or number literals (quoted). Option A uses unquoted identifiers (Up, Down, Left, Right) which are not valid string literals and cause a syntax error.

🚀 Application

expert

Choosing between enum and union literal for a feature flag system

You are designing a feature flag system in TypeScript where flags can be "enabled", "disabled", or "experimental". You want to ensure: - The flags have a runtime representation for logging. - The code is easy to extend with new flags. - Type safety is strict to prevent invalid flag values. Which approach best balances these requirements?

A Use a string enum with explicit string values for each flag.

B Use a union literal type of strings without any enum.

C Use numeric enums and map them to strings at runtime.

D Use a plain object with string constants and a union literal type derived from its values.

💡 Hint

Consider runtime representation, type safety, and ease of extension.

Using a plain object with string constants provides a runtime object for logging and iteration. Deriving a union literal type from the object's values ensures strict type safety and easy extension by adding new keys. String enums provide runtime objects but are less flexible to extend and can be verbose. Numeric enums add complexity with mapping. Union literals alone lack runtime representation.

Practice

1. Which statement best describes a key difference between TypeScript enums and union literal types?

easy

A. Enums create runtime objects, while union literal types only exist at compile time.

B. Union literal types generate JavaScript code, enums do not.

C. Enums cannot restrict values, union literal types can.

D. Union literal types allow dynamic value assignment, enums do not.

Solution

1. Step 1: Understand enums and union literal types

   Enums create named objects that exist in the generated JavaScript code at runtime. Union literal types only exist during TypeScript's type checking and do not produce runtime code.

2. Step 2: Compare runtime presence

   Since union literal types are erased after compilation, they cannot be used as runtime objects, unlike enums.

3. Final Answer:

   Enums create runtime objects, while union literal types only exist at compile time. -> Option A

4. Quick Check:

   Runtime object presence = A [OK]

Hint: Enums exist at runtime; union types do not [OK]

Common Mistakes:

• Thinking union types generate runtime code
• Believing enums cannot restrict values
• Confusing dynamic assignment capabilities

2. Which of the following is the correct syntax to define a union literal type for colors 'red', 'green', and 'blue' in TypeScript?

easy

A. enum Colors { 'red', 'green', 'blue' }

B. type Colors = 'red' | 'green' | 'blue';

C. type Colors = ['red', 'green', 'blue'];

D. enum Colors = 'red' | 'green' | 'blue';

Solution

1. Step 1: Identify union literal type syntax

   Union literal types use the syntax: type Name = 'value1' | 'value2' | 'value3';

2. Step 2: Check options for correct syntax

   type Colors = 'red' | 'green' | 'blue'; correctly uses the union literal type syntax. Options B and D misuse enum syntax, and C defines a tuple type, not a union.

3. Final Answer:

   type Colors = 'red' | 'green' | 'blue'; -> Option B

4. Quick Check:

   Union literal type syntax = A [OK]

Hint: Union types use | between quoted literals [OK]

Common Mistakes:

• Using enum syntax for union types
• Using array syntax instead of union
• Assigning enum with = and union syntax mixed

3. Given the enum and union type below, what will be the output of the console.log statements?

enum StatusEnum { Active = 'active', Inactive = 'inactive' }
type StatusUnion = 'active' | 'inactive';

const enumValue = StatusEnum.Active;
const unionValue: StatusUnion = 'active';

console.log(enumValue === 'active');
console.log(unionValue === 'active');

medium

A. false false

B. true false

C. false true

D. true true

Solution

1. Step 1: Understand enum and union values

   StatusEnum.Active is assigned the string 'active'. The unionValue is also the string 'active'.

2. Step 2: Evaluate the console.log comparisons

   Both enumValue === 'active' and unionValue === 'active' compare string 'active' to 'active', so both are true.

3. Final Answer:

   true true -> Option D

4. Quick Check:

   String equality for enum and union = D [OK]

Hint: Enum string values equal union strings if assigned same literal [OK]

Common Mistakes:

• Assuming enum values are numbers by default
• Thinking enumValue is an object, not a string
• Confusing enum and union value types

4. Identify the error in the following TypeScript code using enums and union types:

enum Direction {
  Up = 'UP',
  Down = 'DOWN'
}

type DirectionUnion = 'UP' | 'DOWN';

function move(dir: DirectionUnion) {
  console.log(dir);
}

move(Direction.Up);
move('LEFT');

medium

A. Calling move with Direction.Up causes a type error.

B. Enum Direction is missing a 'LEFT' value causing an error.

C. Calling move with 'LEFT' causes a type error.

D. Function move should accept enum Direction, not union type.

Solution

1. Step 1: Check function parameter type

   Function move expects a parameter of type DirectionUnion, which allows only 'UP' or 'DOWN'.

2. Step 2: Analyze function calls

   Calling move(Direction.Up) passes 'UP', which is valid. Calling move('LEFT') passes a string not in the union, causing a type error.

3. Final Answer:

   Calling move with 'LEFT' causes a type error. -> Option C

4. Quick Check:

   Invalid union argument = B [OK]

Hint: Union types restrict allowed strings strictly [OK]

Common Mistakes:

• Assuming enum values are incompatible with union types
• Thinking missing enum values cause errors
• Believing function parameter types are flexible

5. You want to create a set of fixed string values representing user roles that can be checked at runtime and also provide type safety. Which approach is best and why?

// Option 1
enum UserRoleEnum { Admin = 'admin', User = 'user', Guest = 'guest' }

// Option 2
type UserRoleUnion = 'admin' | 'user' | 'guest';

hard

A. Use UserRoleEnum because it creates a runtime object for checks and type safety.

B. Use UserRoleUnion because it generates runtime code and is simpler.

C. Use UserRoleUnion because enums cannot restrict string values.

D. Use UserRoleEnum because union types cannot be used in type annotations.

Solution

1. Step 1: Understand runtime and type safety needs

   To check values at runtime, you need an actual JavaScript object. Enums generate this object. Union types only exist at compile time and do not generate code.

2. Step 2: Compare options for runtime checks and type safety

   UserRoleEnum provides both runtime presence and type safety. UserRoleUnion provides only type safety but no runtime object for checks.

3. Final Answer:

   Use UserRoleEnum because it creates a runtime object for checks and type safety. -> Option A

4. Quick Check:

   Runtime object + type safety = C [OK]

Hint: Enums create runtime objects; unions only type safety [OK]

Common Mistakes:

• Thinking union types generate runtime code
• Believing enums cannot restrict string values
• Assuming union types can be used for runtime checks