Have you ever wondered why TypeScript experts recommend avoiding the use of ENUMs? While they may seem like a useful tool for defining a set of con...
For further actions, you may consider blocking this person and/or reporting abuse
This is a rather strange statement considering that typescript always generates more code than you write.
I think he implied: compared to using const.
Ok let check it. I have this code:
What we have:
ConstRoles used 12 times and have 324 characters (27 * 12)
Roles used also 12 times and have 306 (10 * 12 = 120, 120 + 186 enum definition character = 306).
Seems
const enum
occupied more characters thenenum
in this case. Ok may be my example too rude but it reflect my opinion about talks like "for this will be generate more code then for another one" can't will be common it always local and dependece from use case.The article talks compares
Enum and Const
not
Enum and Const enum
Also it talks about
We're not talking about typescript code. We're talking about javascript converted code from typescript. Const has a native type in javascript whilst enum doesn't, so it has to be converted.
Take a look at this (which is the example above in the article):
Playground Link
Even if you copy and paste your code into that playground you can see enum differences with const, also that const enum should be avoid, it's glitchy sometime and bundle size wise it's better to use const. In some case it's just better to use Type, rather than also const itself. Depends on what you're doing, but enum should be avoided.
"We're not talking about typescript code." - I'm also talking about JavaScript and all conslusions in my previous comment also about JavaScript not TypeScript.
"Even if you copy and paste your code into that playground you can see enum differences with const" - ok let's compare it:
and
I see only one difference
Roles
defined withvar
,Roles1
defined asconst
. Constant onRoles1
not guarantee anything actually. I can to do in consoleRoles1.Admin = "writer"
and yes it will be works. Correct way to do constant is makeObject.freeze(Roles1);
after definition of object. Another way isconst RolesAdmin = "admin"; const RolesWriter = "writer";...
."it's glitchy sometime" may be don't use TypeScript at all if it have glitches? :)
Good article!👏
You could also use enums in combination with
interfaces
,types
ofclasses
to encapsulate the behaviour of theenum
, but, to be honest, I don’t really see a usage of anenum
. You have far better solutions which are type safer such as string literals:This adds the benefit of preventing typos because that allow you to match the exact string value that is desired to be used. You have other better solutions as well, but this one should be a good one to replace the usage of an
enum
.sure, but exept when your strings were too lang.
I prefer unions. More portable, you still get auto-complete and they are compiled away from the code into types only, without ever reaching the JavaScript output.
They also support codebase-wide renaming for most but a few edge cases.
type RoleKeys = typeof Roles[keyof typeof Roles]
This line basically generates union from Roles object, still giving you access to "enums-like" syntax:
Roles.Admin
Union types, a.k.a. unions, are types, too. You know, like
Yes of course they are also types.
Great article!
If you write export const enum you won't generate single value.
And it will compile to nothing and in thee code it will have the hard code value
export const enum Enum {
FIRST = 'name'
}
I like the string Enum approach and I haven't face those issues when trying to use the real string instead of the enum key.
If you need to explicitly pass the string, you can use "as" to force its mapping. It will map perfectly with the string value of your enum.
I know we should avoid using "as", but it's a very unlikely situation (I can't think in a use case to explicitly pass a string if I have the enum keys).
I think the most common use case will be to match data received from the backend (string) with the frontend enum type. But just using "as" will map perfectly.
Based on the example in the article:
And by using enums instead of "objects as const", I don't need to do things like
RoleKeys = typeof Roles[keyof typeof Roles]
just to be able to use it.the down side to doing something like
hasAccess("fish" as Roles)
you are basically saying, trust me TS, I know this is right. which is the danger that the article is warning about.Well, i.e. in the paragraph above, you write how bad it is that the typescript does not check that the value is in the range of the Enum. And here you write how to make it possible for strings, which will eventually lead to the same problems in the future as in the previous example.
May be you share examples in post?
Example from "Numeric types usafe" is no longer relevant since TypeScript 5.0
Articles like these are great 👍 very good explanation of the problem and the solution! Many thumbsup 👍👍👍