|
|
|
|
|
|
by brundolf
1353 days ago
|
|
|
> Now try this 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 theseBut 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 |
|
|
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.