| I think enums should be avoided for a few reasons not described in the article (some of them are mentioned in other comments here). 1) Enums have a unique (and, imo, mostly undesirable) model for interacting with the rest of the type system, which isn't what you'd naively expect. If you try to treat an enum like an object-literal (`as const`) when it comes to type-level manipulation you're going to have a bad time. 2) Implicit numeric enums (i.e. the ones most people use by default because they require the least amount of typing) make adding new values a _backwards-breaking change_ if you insert them before existing values, and you send them over the wire. Let me repeat that: adding new values to an existing enum is a _breaking change_. 3) Giving a field or parameter an enum type will not actually cause the Typescript compiler to complain if you put in a value that's not part of the enum! Example: ```
enum Fruit {
APPLE,
BANANA
} interface FruitSalad {
base: Fruit
} const salad: FruitSalad = {
base: 5
};
``` Assigning `5` to `base` (which, you might expect, would only accept `Fruit.APPLE` and `Fruit.BANANA` - and perhaps even `0` and `1` as valid values) is in fact something that the compiler will let through without complaint. 4) Debugging is a headache, since reverse-mapping them gives you... a number. You might say that most of these problems are solved by using string enums - sure, but then why not use an object literal instead? To save yourself from needing to write a single additional type definition? IMO, that is not worth the issues you run into with respect to the first problem. |