Enums & Alternatives

## What an enum declaration is An `enum` declares a named set of members and, unlike almost everything else in TypeScript's type layer, it is **not** erased at compile time — it emits a real JavaScript object. That means each member has an actual runtime *value*, and the rules for where that value comes from are worth knowing precisely. A member gets its value in one of two ways: you write an initializer (`Up = 1`), or you leave it bare (`Down`) and the compiler computes one. ## The numeric auto-increment rule The rule is simple and mechanical: - A bare **first** member is `0`. - Any other bare member is *the previous member's value plus one*. ```ts enum Status { Active, Done } // Active = 0, Done = 1 enum Direction { Up = 1, Down, Left, Right } // 1, 2, 3, 4 ``` Starting at `0` is the default that trips people up most often — many candidates assume the sequence starts at 1, which is why `enum Direction { Up = 1, ... }` is such a common idiom in real code: the author wanted 1-based values and had to say so. ## Restarting the sequence The counter is not global to the declaration; it resumes from whatever the previous member ended up as. So you can restart it as many times as you like: ```ts enum Code { Ok = 200, Created, // 201 BadRequest = 400, Unauthorized, // 401 } ``` This is genuinely useful for grouped codes, and it is also the reason a careless edit is dangerous: inserting `Accepted` between `Ok` and `Created` shifts `Created` from 201 to 202. ## Why string members cannot auto-increment There is no successor operation on strings. "LOW" plus one is not a value the compiler could invent, so TypeScript simply requires an initializer for every string member: ```ts enum Level { Low = 'LOW', High } // ~~~~ error TS1061: Enum member must have initializer. ``` The error is reported on `High`, not on `Low` — the declaration of a string member is fine; what is impossible is the *bare member that follows it*. This matters for reading the diagnostic correctly: the compiler is telling you "I cannot derive this one", not "string enums are illegal". The same rule fires in a mixed ("heterogeneous") enum. TypeScript permits mixing numeric and string members in one declaration: ```ts enum Het { No = 0, Yes = 'YES' } // legal enum Bad { No = 0, Yes = 'YES', Maybe } // error on Maybe ``` Mixing is legal but generally discouraged, because the resulting object has members of two different value types and consumers can no longer make simple assumptions about what a member is. ## The stability consequence Auto-increment couples a member's value to its *position* in the source. That is harmless while the values live only inside one running program. It becomes a data-integrity problem the moment those values leave the process: written to a database column, sent over the wire, stored in a log, or persisted in a browser's local storage. ```ts // v1 — rows in the DB store 0, 1, 2 enum Role { Viewer, Editor, Admin } // v2 — someone inserts a member alphabetically enum Role { Admin, Editor, Viewer } // every stored row now means something else ``` Nothing in the type system catches this: the code still compiles, and the old rows still hold valid numbers. The defence is to pin every value explicitly (`Viewer = 0, Editor = 1, Admin = 2`) or, better, use a string enum whose values are self-describing and cannot be renumbered by a reordering. ## Reading it back Because the values are real, you can compute them mentally by walking the declaration top to bottom, and you can verify them at runtime with a `console.log`. That is the whole trick to the interview question: state the two rules (first bare member is 0; each subsequent bare member is previous plus one), note that explicit initializers reset the counter, and explain that string members have no derivable successor so the compiler demands one for each.