> seeing `Direction.North` is a whole lot more semantically meaningful than the string "north" in code
This is subjective, so we can agree to disagree, but personally assuming I have typechecking/autocomplete I really prefer knowing exactly what I have (a string), and not hiding it behind an abstraction
And, if you ever just want the values enumerated for whatever reason, you can always do it yourself explicitly:
const Direction = {
North: 'North',
South: 'South',
East: 'East',
West: 'West'
} as const
type Direction = keyof typeof Direction
Compared with the above, the special enum syntax just creates unnecessary magic in my opinion; it even breaks TypeScript's rule of not having any runtime footprint
> More than that, refactoring tooling Just Works with enums
1. When I typed open-quote in front of `=`, it intellisensed/autocompleted on the possible strings
2. I was able to right-click 'A' in the type definition, click "Rename...", and then it updated both the type and the 'A' literal value with the new value
type MyEnum = 'a' | 'b' | 'c';
function test(val: MyEnum) {
return val;
}
// refactors
test('a');
// does not refactor
const testVal = 'a';
test(testVal);
The simple fact is that- as far as the type system is concerned, enums are more than simple strings, and they are useful for those differences.
As for the readability, it gets a little more interesting when you are interacting with libraries or APIs outside of your control; you end up with hyphenated things, underscored, and other oddities that may not be a one-to-one match between a logical, easily readable key and the underlying value it represents.
Sure- the auto-refactor won't work here, only the typecheck, and that's the desired behavior in this case because the intended use of 'a' is not necessarily known at that point in the code. Which is the point you're making I guess, though I have to say, in practice this is an unusual case that I never really see; usually if I'm creating an enum-string it's directly in a function call, typed object literal, etc.
> as far as the type system is concerned, enums are more than simple strings
enum MyEnum {
Foo,
Bar
}
function test(val: MyEnum) {
return val;
}
test(MyEnum.Foo)
test('Foo')
I was surprised to find you were right about this; I expected the above to pass checks, but it doesn't. TypeScript actually does treat the enum as more than just its underlying value. So that's interesting- and that's the first reason I've really seen to use these
But I think I still prefer plain values, for myself. There's just something that feels right and pure about using plain JSON-like JavaScript values, and then overlaying types on top of them that have no effect on their behavior and don't obscure their underlying representation. You know exactly what you've got, it's maximally duck-typeable, it's unchanged when it gets (de)serialized, it all just feels better to me
>though I have to say, in practice this is an unusual case that I never really see
They happen once in a blue moon and when they do, you hate your life for a day. Maybe a week.
Plain values also have the problem of losing context. This primarily hits those who don't know the code. That's the whole selling point of OOB and related abstractions, anyway.
Both of the above happening in tandem isn't that rare and a realistic risk factor for big projects.
I'm not sure why I would? TypeScript would still lead me straight to the problem via type incompatibilities; it just wouldn't perform the fix for me automatically in this one specific case
Here, TypeScript infers that it is of type "string", and knows the value, so it is perfectly happy accepting it to ALSO be of type MyEnum. This is the problem- refactoring MyEnum means that testVal is not automatically updated, because the type is really "string" that just-so-happened to duck-type into MyEnum at the function call site.
On the other hand, if MyEnum were actually an enum rather than a union of strings, this problem wouldn't have happened.
This is subjective, so we can agree to disagree, but personally assuming I have typechecking/autocomplete I really prefer knowing exactly what I have (a string), and not hiding it behind an abstraction
And, if you ever just want the values enumerated for whatever reason, you can always do it yourself explicitly:
Compared with the above, the special enum syntax just creates unnecessary magic in my opinion; it even breaks TypeScript's rule of not having any runtime footprint> More than that, refactoring tooling Just Works with enums
I just entered the following in my editor:
1. When I typed open-quote in front of `=`, it intellisensed/autocompleted on the possible strings2. I was able to right-click 'A' in the type definition, click "Rename...", and then it updated both the type and the 'A' literal value with the new value