The TRUTH About TypeScript Enums
HTML-код
- Опубликовано: 4 мар 2024
- Many people dislike TypeScript Enums. I actually like them!
Matt's Videos on Enums - • Enums considered harmful
Total TypeScript Course - www.totaltypescript.com/
*Newsletter*
Newsletter 🗞 - www.jamesqquick.com/newsletter
*DISCORD*
Join the Learn Build Teach Discord Server 💬 - / discord
Follow me on Twitter 🐦 - / jamesqquick
Check out the Podcast - compressed.fm/
Courses - jamesqquick.com/courses
*QUESTIONS ABOUT MY SETUP*
Check out my Uses page for my VS Code setup, what recording equipment I use, etc. www.jamesqquick.com/uses
Based on Matt's video, I've already made the transition to POJOs. I like the flexibility of hardcoding strings, while still getting error checks and intellisense
Fair enough. Just not the way I think about it. Glad that's working for you!
I could be wrong but using “as const” object as alternative to Enum isn’t new and is a widely used typescript pattern. So personally I don’t see why it’d cause confusion. And this pattern is even mentioned as alternative in modern typescript in the typescript official documentation under the Enum section.
My personal preference is to stick with object because it’s predictable vs you get so many quirks with Enum.
I'm not saying "as const" specifically causes confusion. I think the TypeScript that comes with it to get typings adds some confusion though. Regardless, I agree, it's a perfectly valid way to do this
Pocock's magic typescript is just using a keyof operator which every typescript dev should use.
I think the disagreements about being able to use strings instead of enums is a good consideration but just a preference and depends on what you're trying to do in the code
Great point at 8:33 . Sometimes you work with javascript codebase and people whom you try to convince to switch to Typescript. The simpler the better in those cases. It all depends on context.
the point is basically 'i am dum dum, so as const is bad and enums are good'
and don't talk to people who need to be convinced to switch to TS in 2024. These are dinosaurs
4:34 If you're working in a company like mine where you have like 20+ packages, this can get really cumbersome. We have rules to not import from the src directory which means all the enums you use for a component property in a package need to be exported explicitly. Often when someone else builds a package you're using and for example, you're trying to inherit a type(with enums) from it, it can be so problematic because that enum has to be exported explicitly while union with values solve so many of these issues.
What is the name of the extennsio that shows online values when you are writing??... it is nice ..
i like your critique. it was really eye opening. you answered a lot of the questions i had after watching his video. thanks.
Wow, so glad to hear that! Thanks for wathching!
I've been using POJO and always will.
I like simplicity 😅
What is pojo?
@@aestheticallyamazing2003 Plain Old Javascript Object
Plain Old Java Object?
I watched it before Matt's video, with as const another set of problems opens up :D,
something like this Array of Foo not assignable to Readonly Array of Foo
so I use both things interchangeably
enum Status { Close = 0, Open = 1 ...etc}
I have a lot of things stored in the database like this as a integer
I wonder in const a = {name:"Peter") as const, why use "as const" if it is already assigned to const a?
I've a pretty nice example for the last plain javascript part, I'm in a situation where i need types value in booleans with associated name for developing. tried to use enums but it does not infers into booleans. I can use this as const method to declare types of " transaction = { Debit : true } " that made it pretty easy.
why not use JSON for 'fake database data' and ts Types for intelesense?
I like both. I don’t feel like enums deserve all the hate. I can say I have ran in to edge cases with both that I found frustrating. So I tend to use an enum if I am going to build tightly coupled components and I don’t intend to share the enum around my app or apps. I use the as const if I’m building something that needs to be more generic and can be shared and reused all over.
But per your comment in the video. If the intent is to have teammates use exact strings that I know might change I think the enum is the right tool.
Excellent topic and great counterpoints. Aside from the weird index thing, I agree with you that they behave exactly as I would expect them to with no added complexity. Yeah Matt is the 🐐 for Typescript. 💪
Agreed on both points! lol
Ever since I have discovered as const, I can't really go back to enums. I have used them before, but moved over to using string unions instead. The downside of unions is the inability to iterate over them, hence as const is a nice way of solving all the issues and limitations of enums and alternatives.
Nice! Glad you found something that works.
Fight the system! I stand with you ! Enums are great!
Great vid.
Would I use Enums or 'as const objects'? I think the answer as always is "it depends". But I do tend to lean a bit more towards objects than enums. My main reasoning being objects are JS native and transpile predictably, while enums are purely TS and can do the weirdness with keys etc that you both describe.
Thanks for sharing. I question the "JS Native" part simply because of the other TypeScript lines that are included after the POJO. Also "as const" is TypeScript not JavaScript. So you still have transpilation going on for the majority of that code lol
@@JamesQQuick That's fair. I was meaning more the concept of objects vs enums in JS. With the TS after the POJO informing the linting/typechecking, rather than being code that is run.
But, you're right. The 'as const' isn't JS, and the same with the additional TS lines after the POJO. Which does mean there's transpilation, the 'as const' and typedefs are stripped (though I could be wrong on that). In my opinion that is more predictable than to an IIFE that may, or may not, add additional keys depending on whether string values are used.
Great vid. I think you already know my take on this. 😅 I'll just mention that to me, avoiding usage of something because some people may not be familiar with it isn't necessarily a reason to avoid it. There's plenty of features in languages that are there for a reason even if we don't reach for them often. That said I agree that the end of the day it really doesn't matter *that* much which one you use, as long as it works well for you and your team.
Yeah I agree with that as well. It's not the specific reason I'm choosing not to, just something worth noting. Thanks for watching and sharing your thoughts!
I see your point, and I agree that most of people wouldn't be able to understand Matt's alternative (yet produce it, or even use it effectively in a codebase). But at the same time I think it's important to point out few things.
1. The use of reverse mapping is beyond just calling a method with a string where we should've used the enum, it's the ability to get the enum from a string (e.g. you have an error status code, and you want the get the enum from it. Or you have string file names and you want to get the enum for the extensions ...).
2. Why enum in general feels "odd" in the world of TS is because they behave differently. TS type system is based on the "shape" of the objects, (i.e. if object A is of type Person, and object B is of a type that fits the description of a person, then we can use B where we used A and viceversa). You cannot do that with enums as Matt explained, and that's enough reason for me to at least try to avoid them when possible, specially for TS newcomers because it will confuse them.
With that said I loved the video, and I loved how you respectfully shared your opinion while giving credit to Matt 🎉
Thanks for watching and sharing your thoughts! :)
Getting to a point (with TS) when i need to rename keys, cascade from one type into a new type or other advance TS, in my humble opinion means you didn’t do your stuff right from start and when i say start, i mean diagrams, scenarios, before first line of code.
Beside this, have one of “Matt” in team, with his advance TS level will only get latency on development, lets not forget for what TS is made: enforce addresses to accept type, avoid js dynamic type.
Or maybe im wrong 😑
Oh and beside this, “as const” beside making it readonly, you can use it as type, the type being the literary value not type of const value. Basically another kind of Enum with keys value defined.
Oh James ! There's a real topic around Enums. I really doubt about using them! Prefer to use types and typeof
i want to minimize imports like importing enums
Oh man , i had always in this mind why enums are so compliacted in typescript. i also think same as you
Easy to use:
const roles = {
admin: 'admin',
user: 'user',
} as const
type Role = ValueOf
declare type ValueOf = T[keyof T];
I have no idea why you need "enum"
If you will have library enum and codegen enum(from prisma / gql for exmaple) and they will be identity or one of the options would be more of a narrow type, they'd all be incompatible
do you know how devs fix it? just cast, nice "safety" method (nope)
Nobody must use enums, it must be removed
Same guy that wrong c# wrote typescript. Enums are a staple of c# they are a value type and work the same way. Typescript isn’t applied when you reading PRs from GitHub. Being able to quickly distinguish between strings and Enums is very valuable. To many things look like a hard coded string in JS/TS
Lol just checked, it works this way with ANY NUMBER:
enum A { one: 12, two: 345 } ==> ["one", "two", 12, 345]
I've used both kinds probably just as much as the other, and I honestly think if you're looking to make something rigid, go with Enums, they are simpler to define, and there's only one way to use them so there will be consistency in the code. Freedom sometimes takes away the consistency imo.
I think this is the problem of typescript and JavaScript in general to always add different rules and work around that lead to misunderstanding and always provoking feelings of skill issues. Getting some interest to strict typed languages you realize that these native features are working as expected you have to learn how and when to use them. Enums are great and following the typescript documentation they have to be used in a certain manner. Great video
I respect Mat's wisdom on typescript, but I am team Enum.
I love the strictness, though I also use the "POJOs" it just depends on how I want to use something.
I like Matt's version but comment it do to I underestand it is hard to understand.
If you want to just use a key and the value does not need to be different can use an array as const with a bit of TS.
I would never use object.keys on an enum, never even ocurred to me that you could because I wasnt thinking of them as an object, I also agree that the entire point of using enum is to avoid hardcoded strings
matt pocock might know a lot about typescript but what software has he actually built?
Totally love your points here, makes so much sense to me, and it's really how I use enums in Angular. Once the surprise passed that, ok, we should always give values to our enums, then you can get rid of all the strings parameters in many places, and I think it does serve its purpose.
And also, totally agree, Matt level is so high, I can't produce that kind of code without serious hints.
Anyway, thanks James, fuel for thought 💪🙂
Also, the argument about the "readable values" doesn't make too much sense to me, since I often work with i18n apps, and I don't want to ever think that enums contains anything other than keys.
Enums❤
Regular ENUMS as you have used is 100% the way to go.
For me this removes the need for hard coding strings.
If you haven’t worked in a large repository before you don’t know how bad hard coded strings can be especially when refactoring.
Plus the example with POJOs is simply more code to get the same functionality from a traditional enum using a key and value.
Thanks for sharing your thoughts!
Seems like Matt is forgetting the sole purpose of typescript sometimes. Thanks for the heads up, James.
YEAH, Matt and other "typescript masters" or whatever the hell they are called are 100% using typescript for the only sake of typescript itself, like using english language to write a poem. But we use typescript to make programs do stuff lol, and James take here is much more honest and practical
TS currently follows a “duck typing” system. ie if two types are the same you can use them in place of each other. TS also has a philosophy of having TS disappeared in transpilation or in other words TS shouldn't leave code artifacts behind. Enums are the exception to this because it was early in the TS life and these philosophys hadn't been added.
Matt and others like him advise against Enums because they go against the grain of TS in its current state
I just don't see any valuable reason to use enums over type literals or objects except when it comes to log levels examples.
People usually use enums for values that aren't supposed to change or to avoid typing the same string all over the codebase in case they need to change it. And that's my biggest issue with enums is that they allow you to change their underlying value and typescript will think everything works as expected. It's especially worse for DB related stuff because the underlying value should never change and get out of sync with your db.
Just found this issue in our api a few weeks back. I'd much rather hardcode strings and rewrite the same string in multiple places and get a typescript warning all over the codebase when someone tries to change that value as opposed to enums saying everything is fine. It's too easy for a dev to come and change the values of the enum due to whatever reason and not realize that this value is how it's stored in the DB and lead to all sorts of issues.
There is nothing wrong with passing nromal strings if everything is typed correctly. That's the whole point of TS. Not sure what you point was in 4:45min. TS will check the value itself if you type it correctly, so there is no problems there. I stopped watching, i should start making videos honestly...
switching from "as const" to "enums" after your video, enums look simpler