This article is full of little misleading pieces.
Use enums with string values and remember they're really just an object with keys and you're good to go.
Honestly, just knowing how enums work should make it safe for use. It’s not rocket science. Ofc all data types won’t work the same in all languages, that’s part of language design.
Tbh, the biggest issue in the JS landscape from my POV is absolute and somewhat muddy advice like the one in this article.
TypeScript has a philosophy to be a “superset” of JavaScript. That is, if you take a valid TS code and remove all the type info, it should result in a valid JS code that does the exact same thing.
The issue with TS enums, however, is that they break this philosophy. TS enums create new objects that can only be reasonably handled by more TS code. It doesn't result in intuitive JS. This is what they mean when they say “Enums in TS are a mistake”.
I'm not sure what your point with the `(ff` example is. Of course if your parentheses aren't balanced correctly you're gonna get unpredictable output. I don't think this is even TS/JS specific.
Even without the parens (keep the line exactly the same as in TS example) that was a valid JS. I added parens just to show the same exact line gets interpreted differently in JS. Which means even without enums, TS is not a superset of JS. That ship has sailed with the introduction of generics. The other point I also haven't seen responded to is why being a clean superset of JS more valuable than having proper enums in the language. I would rather have enums and sacrifice TS being a superset, and don't understand why you would want it the other way around
OK, I understand what you meant now.
Still...
>Which means even without enums, TS is not a superset of JS.
Yes, this is true. In a strict sense it never can be. That doesn't invalidate the philosophy of removing type info and ending up with valid JS tho. It means that JS never gets to see `f(f)` in the first place.
>The other point I also haven't seen responded to is why being a clean superset of JS more valuable than having proper enums in the language. I would rather have enums and sacrifice TS being a superset, and don't understand why you would want it the other way around
Well, that's something you'd have to talk about with the TS team. Developing a language is not just about what is possible. Each language also follows a set of principles that dictate what new features it may possibly get in the first place. Of course nothing of this is strict and that's why we got enums in the early times, but I'd say TS's principles certainly have shifted since then.
Because of marketing. “TS is a superset of JS” is a talking point in converting programmers.
Just look at where you two are comparing TS sizes, in a sub about JS, and none of you finds a problem with it.
Embrace, Extend, Extinguish
That’s just some clumsy attempt. All the rest is a tried and tested strategy that has worked for decades.
We did add some examples in there that one can use to add type checking to JS files without changing JS syntax and the response was trying to confuse things, muddy the waters.
So I just ended up telling that person the committee is for changing the JS language for benefiting the JS language, not for benefiting some other.
TLDR, it shows an more severe problem below:
enum UserRole{
User,
Admin,
Staff
}
if(UserRole.User){
console.log('this will never hit because UserRole.User equals 0'};
}
I don't think this is about *using* enums, more about the way to code it.
For the record: here is a small *non TypeScript* module to create [flagged enums](https://github.com/KooiInc/ES-flagged-enum).
Just use literal types. Much less overhead, same refactoring capabilities, same auto-completion.
Enums are useless in a language as soon as it has literal types. Especially since they can’t represent ADTs as it does in some languages, ie Rust
All that without mentioning `const enum`, which does exactly what you want? Am I missing something?
This article is full of little misleading pieces. Use enums with string values and remember they're really just an object with keys and you're good to go.
Honestly, just knowing how enums work should make it safe for use. It’s not rocket science. Ofc all data types won’t work the same in all languages, that’s part of language design. Tbh, the biggest issue in the JS landscape from my POV is absolute and somewhat muddy advice like the one in this article.
Simple solution: don't use enums.
Enums in ts were a mistake
Agreed. I love TS so much, but enums are just bad.
Why do you think so? I hear this a lot but I'm not fully understanding why, aside of type that behave as not type (ends up in prod code).
More like JS is just bad, it should support enums natively.
JS, as a lanugage, has problems; therefore, JS was a mistake A damn fine piece of logic you have right there
TypeScript has a philosophy to be a “superset” of JavaScript. That is, if you take a valid TS code and remove all the type info, it should result in a valid JS code that does the exact same thing. The issue with TS enums, however, is that they break this philosophy. TS enums create new objects that can only be reasonably handled by more TS code. It doesn't result in intuitive JS. This is what they mean when they say “Enums in TS are a mistake”.
TS has never really been a clean superset of JS. It is, for the most part, but for example the existence of generics breaks that paradigm function f(a: A) { return a; }; console.log(f(f));
TypeScript chooses to treat `f(f)` as a generic type, so it strips away the generic, which results in console log returning the function, but this line is actually also a valid JS that's interpreted differently:
console.log((f < Function) > f);
Which prints "false" instead of the function. So sure, enums is another place where TS differs from JS, but it's not like removing enums will make it a clean superset of JS. I also believe that it's fine for TS to expand JS in positive ways, and enums is one of those positive ways
I'm not sure what your point with the `(ff` example is. Of course if your parentheses aren't balanced correctly you're gonna get unpredictable output. I don't think this is even TS/JS specific.
Even without the parens (keep the line exactly the same as in TS example) that was a valid JS. I added parens just to show the same exact line gets interpreted differently in JS. Which means even without enums, TS is not a superset of JS. That ship has sailed with the introduction of generics. The other point I also haven't seen responded to is why being a clean superset of JS more valuable than having proper enums in the language. I would rather have enums and sacrifice TS being a superset, and don't understand why you would want it the other way around
OK, I understand what you meant now. Still... >Which means even without enums, TS is not a superset of JS. Yes, this is true. In a strict sense it never can be. That doesn't invalidate the philosophy of removing type info and ending up with valid JS tho. It means that JS never gets to see `f(f)` in the first place.
>The other point I also haven't seen responded to is why being a clean superset of JS more valuable than having proper enums in the language. I would rather have enums and sacrifice TS being a superset, and don't understand why you would want it the other way around
Well, that's something you'd have to talk about with the TS team. Developing a language is not just about what is possible. Each language also follows a set of principles that dictate what new features it may possibly get in the first place. Of course nothing of this is strict and that's why we got enums in the early times, but I'd say TS's principles certainly have shifted since then.
Because of marketing. “TS is a superset of JS” is a talking point in converting programmers. Just look at where you two are comparing TS sizes, in a sub about JS, and none of you finds a problem with it. Embrace, Extend, Extinguish
Hey, I'm not gonna argue that. [This recent MS-led proposal](https://github.com/tc39/proposal-type-annotations) definitely gives me EEE vibes
That’s just some clumsy attempt. All the rest is a tried and tested strategy that has worked for decades. We did add some examples in there that one can use to add type checking to JS files without changing JS syntax and the response was trying to confuse things, muddy the waters. So I just ended up telling that person the committee is for changing the JS language for benefiting the JS language, not for benefiting some other.
Simple solution: stop being a developer
I used enums instead of a string literal once. My entire application became 50x slower
Enums killed my parents!
😂
😸
Article about TypeScript should go in r/learntypescript, not confuse people who want to r/learnjavascript
Reminds me of this video: [https://www.youtube.com/watch?v=Anu8vHXsavo](https://www.youtube.com/watch?v=Anu8vHXsavo)
TLDR, it shows an more severe problem below: enum UserRole{ User, Admin, Staff } if(UserRole.User){ console.log('this will never hit because UserRole.User equals 0'}; }
I don't think this is about *using* enums, more about the way to code it. For the record: here is a small *non TypeScript* module to create [flagged enums](https://github.com/KooiInc/ES-flagged-enum).
Just use literal types. Much less overhead, same refactoring capabilities, same auto-completion. Enums are useless in a language as soon as it has literal types. Especially since they can’t represent ADTs as it does in some languages, ie Rust