Switch vs If/Else in TypeScript

A deep dive into switch vs if/else in TypeScript. Discover when to use each for optimal readability, performance, and clean code.

Introduction

When you’re choosing between a switch statement and an if/else chain in TypeScript, prioritize intent and clarity. Use switch when you’re comparing one value against several known constants. Use if/else when you need complex boolean logic, range checks, or conditions that reference multiple variables. Modern engines minimize performance differences, so readability and maintainability should guide your decision.

A high-level comparison of conditionals

Choosing between if/else and switch isn’t only stylistic—it's a design choice that affects readability, debuggability, and future maintenance. Both answer the question “what runs next?” but they communicate different intent to the reader.

Core differences at a glance

The goal is clarity. A switch signals: “I’m checking one variable for multiple outcomes.” An if/else chain signals a sequence of distinct tests. Choosing between them makes your code more self-documenting.

Syntax and behavior

An if evaluates any boolean expression and exits the block when a condition is met. A switch evaluates the expression once and compares with case values using strict equality.

Because switch uses ===, it’s not suited for range checks or composite boolean logic such as score > 90 or user.isActive && user.hasPermission.

Fallthrough: a common pitfall

switch statements support fallthrough when a case omits a terminating break, return, or throw. That can cause the next case to execute unintentionally, producing subtle bugs. Linters can catch missing breaks automatically, and explicit comments help when fallthrough is intentional.¹

if/else blocks don’t suffer from fallthrough—each branch is self-contained and exits the structure when executed.

Variable scoping in switch vs if/else

if/else blocks create lexical scopes for let and const. A switch shares one scope across all case blocks, so declaring the same block-scoped variable name in multiple case blocks will error. Wrap each case block in braces to scope variables locally:

const status = 'active';
let message: string;

switch (status) {
  case 'active': {
    const user = 'Admin';
    message = `User is ${user}`;
    break;
  }
  case 'inactive': {
    const user = 'Guest';
    message = `User is ${user}`;
    break;
  }
  default: {
    message = 'Unknown status';
    break;
  }
}

Performance: what matters today

The idea that switch is always faster is outdated. Modern JavaScript engines use Just-In-Time compilation and runtime optimizations that blur performance differences between switch and if/else in real-world apps.² Focus on readability and maintainability over micro-optimizations—network requests, rendering, and heavy data processing are far more likely performance bottlenecks than conditional logic.³

How engines optimize

Historically, compilers implemented switch as a jump table (O(1)) for dense, constant cases. Today, engines like V8 use heuristics and runtime profiling to optimize both switch and if/else paths; they can generate fast lookup strategies and specialize hot code paths when one branch dominates.²

If/else can be fast too

Long if/else chains look linear on paper, but JIT engines perform speculative optimizations and inline caching that make common paths very fast. For most applications the practical performance gap between switch and if/else is negligible.

Modern alternatives

As logic grows, both classic patterns can get unwieldy. TypeScript and modern JavaScript offer cleaner, more scalable patterns that favor declarative code.

Object and Map dispatch tables

Dispatch tables map keys to functions or values. They convert procedural conditionals into lookups, reduce cyclomatic complexity, and make extending behavior trivial.

Before (switch):

const getStatusIcon = (status: string) => {
  switch (status) {
    case 'success':
      return <SuccessIcon />;
    case 'error':
      return <ErrorIcon />;
    case 'pending':
      return <PendingIcon />;
    default:
      return <DefaultIcon />;
  }
};

After (object dispatch):

const statusIcons: { [key: string]: JSX.Element } = {
  success: <SuccessIcon />,
  error: <ErrorIcon />,
  pending: <PendingIcon />,
};

const getStatusIcon = (status: string) => {
  return statusIcons[status] || <DefaultIcon />;
};

This decouples mapping from retrieval. Adding a new status is just adding a new key.

Pattern matching (future)

Pattern matching is a TC39 proposal that promises expressive conditional logic—matching on data shapes and destructuring inside conditions. It’s not finalized yet, but it points to a future where conditionals are more declarative and robust.⁴

Practical TypeScript and React use cases

Certain problems map naturally to one pattern or another.

Use switch for reducers and enum dispatch

Reducer functions (Redux-style) are classic switch territory: inspect a single action.type and return the next state. Using an enum for action types improves type safety:

enum CartActionType {
  ADD_ITEM = 'ADD_ITEM',
  REMOVE_ITEM = 'REMOVE_ITEM',
  CLEAR_CART = 'CLEAR_CART',
}

function cartReducer(state: State, action: Action): State {
  switch (action.type) {
    case CartActionType.ADD_ITEM:
      return { ...state, items: [...state.items, action.payload] };
    case CartActionType.REMOVE_ITEM:
      return { ...state, items: state.items.filter(item => item.id !== action.payload.id) };
    case CartActionType.CLEAR_CART:
      return { ...state, items: [] };
    default:
      return state;
  }
}

Here, switch reads like a router for action types and keeps the reducer easy to scan.

Use if/else for complex validations

Form validation often involves multiple independent rules, so if/else chains work well:

function validatePassword(password: string): string | null {
  if (password.length < 8) {
    return 'Password must be at least 8 characters long.';
  } else if (!/[A-Z]/.test(password)) {
    return 'Password must contain at least one uppercase letter.';
  } else if (!/[0-9]/.test(password)) {
    return 'Password must contain at least one number.';
  } else if (!/[!@#$%^&*]/.test(password)) {
    return 'Password must contain a special character.';
  }

  return null;
}

Each check is a distinct rule that exits early when a violation is found—ideal for if/else.

Team standards and linters

Consistency prevents bikeshedding in code reviews. A simple team guideline—switch for enum-based dispatch, if/else for complex boolean logic—reduces debate and improves readability.

Enforce standards with ESLint and a TypeScript config. Key rules:

• no-fallthrough to catch missing break in switch statements.¹
• max-depth to limit nested if/else complexity.
• complexity to warn on high cyclomatic complexity.

Automated rules free reviews to focus on correctness and architecture rather than style.

Comparison of patterns

Q&A — Common reader questions

Is switch faster than if/else?

No. Modern engines optimize both; pick the construct that makes the code clearer and easier to maintain.²

When should I refactor an if/else into a switch or dispatch table?

If you have many checks against the same variable for constant values, refactor to a switch or—preferably—an object/Map dispatch table for easier extension and lower cyclomatic complexity.

How do I avoid switch bugs like unintended fallthrough?

Enable ESLint rules such as no-fallthrough, wrap case blocks in braces for local variables, and comment intentional fallthroughs.¹

Internal links and further reading

See the TypeScript handbook for enums and discriminated unions: /docs/typescript-handbook

Examples of refactoring conditionals and dispatch patterns: /blog/refactoring-conditionals