Controlling JavaScript Behavior with Conditionals

Table of Contents

1. Challenge

   Step 1: Enforce strict equality in the ticket triage module

   Every JavaScript application eventually asks a question it can't get wrong: is this value actually equal to that one? Get the answer right and users never notice. Get it wrong, and a decision silently routes down the wrong path.

   In this lab, you'll work inside a helpdesk platform's ticket-triage logic, the code that classifies incoming support tickets, flags ones that need a manager's attention, routes them to the right department, and estimates a response time, alongside a small command-line demo that feeds a batch of sample tickets through it so you can see your fixes take effect. To start, you'll look at where that logic compares values coming in from a web form, values that don't always arrive as the type you'd expect, and fixing these comparisons first means every decision downstream, from department routing to response times, can be trusted to depend on the right value and the right type.

   The application directory contains the ticket-triage module, src/ticketTriage.js, and its test suite, ready for the fixes you'll make in this step.

   info> Feeling stuck? Check out the matching solution/stepN/ folder for the step you're on to see a working implementation. Give it a try on your own first. The solution folder is your safety net, not your starting point.

   Strict equality and type-safe comparisons

   JavaScript offers two ways to compare values: loose equality (==), which converts operands to a common type before comparing, and strict equality (===), which only returns true when both the value and the type match. For example, given a placeholder value input and a target target, input == target might return true even when input is the string "3" and target is the number 3, while input === target would correctly return false. Preferring === for comparisons where the type matters keeps a mismatched or unexpectedly typed value from silently slipping through as a match. ### Applying strict inequality to a flag check

   The same reasoning applies to inequality checks: !== is the strict counterpart to !=, and it's the right choice whenever a comparison needs to treat differently typed values as different, instead of coercing them into matching or not matching by accident.

   Loose equality's coercion isn't limited to numbers and numeric strings; it applies to booleans and other falsy values too. A ticket's escalated field should only ever be true or false, but some tickets record an unresolved escalation status as an empty string ('') instead. Because '' coerces to false, '' != false evaluates to false, meaning JavaScript treats the two as equal, so a ticket with an unresolved status is treated as explicitly not escalated instead of being flagged for review.

2. Challenge

   Step 2: Refactor department routing into a switch statement

   With the triage module's value comparisons now behaving predictably, this step turns to a different kind of conditional logic: an if/else chain long enough to become hard to follow. Here, you'll replace the department-routing logic's if/else chain with a switch statement that maps the same ticket categories to the same departments as a set of case clauses. By the end of this step, department routing will read as a flat, readable list of cases instead of a nested chain of conditions, while still sending every ticket to the same department it did before.

   Refactoring branches into a switch statement

   A switch statement evaluates an expression once and matches it against a series of case labels, running the code beneath whichever label matches. Each case needs a break statement at the end, or execution continues into the next case regardless of whether its label matches. A final default case runs when no other label matches, which is the switch equivalent of a trailing else. For example:

   switch (input) {
     case 'a':
       result = 'first';
       break;
     case 'b':
       result = 'second';
       break;
     default:
       result = 'fallback';
       break;
   }
   

   Reaching for switch over a long if/else chain reads more clearly when every branch checks the same variable against a specific, known value.

3. Challenge

   Step 3: Harden the SLA switch statement and run the triage demo

   With department routing now expressed as a switch statement, this step turns to a second switch statement, one that computes a response time based on how a ticket arrived: a switch's cases only stop executing when something tells them to. Here, you'll add the missing break statements and a default case to the response-time switch, then run the module's command-line demo to confirm a batch of sample tickets is triaged correctly end to end. By the end of this step, the response-time calculation will resolve to the case that actually matches each ticket.

   Fall-through in switch statements

   Without a break, a switch statement doesn't stop after running a matching case. It keeps executing every case below it, in order, until it hits a break or reaches the end of the switch, a behavior called fall-through. This means a switch that's missing break statements can match the right case but still end up with the last case's value, since execution just keeps going past the match. For example:

   switch (input) {
     case 'a':
       result = 'first';
     case 'b':
       result = 'second';
   }
   

   Here, input === 'a' still ends with result set to 'second', because execution fell through past the first case without stopping. Adding a break to each case, and a default case for values that don't match anything, makes sure the switch resolves to exactly the case that matched and nothing more. ### Seeing the corrected logic run end to end

   Each fix so far has been verified in isolation by its own test. Running the module's command-line demo exercises the priority classification, manager-review, department-routing, and response-time logic together against a batch of sample tickets, the same way the triage module would run in the real helpdesk application. Nice work. You debugged and refactored the ticket-triage module that helpdesk tickets flow through every day, closing off a type-coercion bug, an if/else chain that had outgrown its structure, and a switch statement that silently fell through.

   Along the way, you practiced telling JavaScript exactly what you mean when comparing values, choosing a switch statement over a long chain of conditions, and controlling exactly where a switch statement stops executing with break and default. Those are the same conditional-logic decisions that show up in almost every JavaScript codebase, not just this triage module.

   When you ran the demo, you saw all three fixes work together: a string-typed priority correctly falling back to unspecified, an unresolved escalation status correctly flagged for review, and an unrecognized category and channel both landing on their default values instead of silently producing the wrong answer.