Now you might have noticed that we don't have a lesson on TypeScript in NUMs. That is because I don't recommend using them for professional use. So in this lesson we will look at a comprehensive list of all the reasons, uh, why you shouldn't use TypeScript NUMs. And not only that, we will also provide alternatives that you should use. So let's go. Now, the first reason, and this is probably the biggest one, is that they are not a part of standardized JavaScript. Back then when TypeScript was originally introduced, there was a proposal to sort of put them within JavaScript, but that proposal hasn't seen any significant traction.

TypeScript works best when you think of it, is a type only addition to JavaScript and currently Enums break this rule to understand more reasons why they are harmful. Let's take a look at how they work within TypeScript. Let's create a simple enum for two ways that the user can log in called login mode and the values are email and social. Now at runtime, the values are going to be numeric by default and they'll start off at zero and then increment by one for each new member. You might already see an issue with this. For example, if the next developer comes in

and adds another login mode called app and does the great job of putting it in alphabetic order, putting it first. Now email and social are no longer zero and one because app is not zero, email is one and social is two. Now this might not sound like a big deal, but if you are sending these values, for example, over a network, congratulations, you've broken your clients. Now the fix for this is not particularly hard. Make sure that if you are using enums always provide an exact value. So when we initialize, we should provide zero

and one so that that stay a static. And then when app gets added, it must be assigned a different number. I think you can see why this is going to become a problem because you can actually assign two enums the same value, but let's assume that people are going to do the right thing. Another reason why TypeScript ins are bad is that they don't do a great job of the one thing that TypeScript is designed to do, which is provide type safety. So if we have a nice enum with well-defined values, and if you want to use it within a function, we can annotate it to make sure that a login mode is passed in.

And you would hope that Touch Street will of course make sure that a valid login mode value is passed in. And of course you can pass in members by looking them up from the enum and this is definitely going to work reliably. But you can actually also pass in the numeric values. And of course if you provide a valid one, everything is going to work perfectly fine, but you can actually provide an invalid value as well, and types scraped will not complain. Another nail in the coffin of numeric NUS is a feature that feels like a bug. And this feature is a nice lookup

and the reverse lookup that you can do within a nu between the string member names and the numeric values. For example, given the string app, you can see that its value is going to be zero. And given the Value zero, you can see that the key for that is going to be app. Now, as you would imagine in order to support this, TypeScript would need to create an object that has both the string as well as the number values as keys, and that is exactly what TypeScript does. The code might look a bit complicated, but in simple terms, it initializes a new object, passes it as an argument to a function, which then takes the object

and assigns the string members the number. And this equal to number will then evaluate to the number, so it assigns the number member the string. Now even though we've explained the exact J script implementation, you can pretty much deduce it yourself as well because the string gives the number and the number gives the string. Now because of this simple feature, object keys does not return what you might want it to, you would probably want it to return the keys of the interim, which is app, email, and social. But that is not what you're going to get.

You're going to get the keys as well as the reverse keys. I think we've established that numeric nus aren't great, but string in NUMs aren't great either to create a TypeScript inam that is backed by strings, you simply initialize the members with string values. Now, even at this point, I want to point out that this is not very dry. It doesn't follow, do not repeat yourself because we are repeating ourselves by mentioning the same thing in the keys and the values stringing S do, however, fix some of the issues of numeric S.

If you try to get the keys, there is no requirement for a reverse lookup. So you do get the things that you would expect, which is the actual keys. And another thing that they improve is that there are stable open network calls because of course you are forced to assign valid strings, and additionally, they are easier to debug as well. But in addition to the fact that you have to repeat yourself, they continue to increase the ity of our code. Now of course, it is perfectly fine that if you want to write a function that will only take a login mode, you would have to import the type

and then you would have to use it in a type annotation. This is okay. However, if you use a function that requires an enum, it's going to be more verbose than it needs to be. You cannot simply initiate login with a valid member. For example, if you've got the string from a network, you still need to find a way to convert this into an actual num, which you will most likely do with the type assertion. So anytime you have to use sub code, that depends on a num, you have to first bing in the inam and then look up the member from the inam even though it should be able to accept the valid string.

Now, this is not a big deal with a single inam, however, quite commonly in libraries like React components take a number of props, which if you decide to convert to inam, then all of a sudden you're bringing in dozens of imports just to call a simple component. Now that we've talked about why types kits are bad, let's focus our attention on alternatives that Work well with the compile time type only nature of TypeScript and the runtime nature of JavaScript. The solution is going to be pretty obvious. Use something that is type only. For example, a union of string literals,

an immediate benefit is that it follows the dry principle, as you would expect, just like NUMs. You get to use it in a type annotation. And what's great is that you can pass in the valid values without having to first convert them into a special type. And this is actually very strongly typed by typescripts and you even get nice auto complete when you have to provide these string values. Now, an additional concern that people have sometimes is that, does it work with refactoring? Well, yes, it actually works very well with refactoring. If you were to refactor a member of the string union,

anytime that particular union is assigned, TypeScript will natively refactor that string literal for you. Simple unions of string literals is what I use most of the time. Now, some of you might want additional features that are provided by NUMs in other programming languages, like a list of valid values that you can iterate over. And there are neat JavaScript native patterns for that as well that we can add simple annotations to without having to resort to TypeScript NUMs. For example, we can create a simple object where the keys and the values are the same,

and we can add the special annotation called as consed. That basically enforces that all the values are narrowed down to their literals. So instead of device being a string, it would actually be exactly the literal string device. And then we can infer that literal union that we had before, which is device, email, and social by first looking up the type inferred for this JavaScript object, and then getting the type of the keys for that particular object using the TypeScript key of operator. So login mode would be the same union

that we previously had, which means that it has all the same benefits. For example, we can use it in a nice type annotation for a function. And of course, this means that we can pass in the literals just like we did before, as long as they are valid. Now the object comes in handy if you want to do a lookup instead of typing in a string. And additionally, it gives you a nice access to the valid values if you want to use them.