DEV Community

TypeScript Best Practices — Using Enums

Stephen Gbolagade on December 10, 2024

TypeScript is not just about validation, It's also about structure and today, let's talk about using ENUMS to save your team unnecessary hours of d...

Read full post

Tom Österlund • Dec 10

I like using enums too for objects.

TS-team however, recommends we use objects instead, like:

Object.freeze({
 Vendor: "VENDOR",
  Customer: "CUSTOMER",
  Rider: "RIDER"
})

enums have some type-safety issues: dev.to/ivanzm123/dont-use-enums-in...

Stephen Gbolagade • Dec 10

This is a good take

Mordechai Meisels • Dec 10 • Edited

No, use string unions instead.

Enums introduce a runtime construct and typescript should only be a compile-time tool.

Unions gives you all the type safety and -- for libraries -- works for JavaScript (i.e. non typescript) projects flawlessly.

José Pablo Ramírez Vargas • Dec 12

I get what you mean, but what you say is wrong: It is a compile-time tool, or better stated, a transpilation tool since JS is not compiled by today's tools. Today's tools transpile, bundle and minify, but don't compile.

What you meant to say is that TS should not "write extra code", or at least this is what I think you meant. If I'm correct, that's also wrong: TypeScript, depending on the target version of ECMAScript, will generate code accordingly. By design, TS is meant to support as much as possible all the newest syntax ahead of time, and is ready to shim on the fly.

Finally, there is no absolute "best" enum. String unions are nice, but numeric enums are great:

A numeric enum only consume a fixed number of bytes regardless of its value, while a string consumes bytes depending on the string length.
A numeric enum can be used as a set of Boolean values when its values are single bits, and both read and write operations are O(1).

Scott Crossan • Dec 12

Came here to say this

Dmitry A. Efimenko • Dec 11

Enums in typescript are not great. Most of the time when you're thinking about using enums, try using string literal instead:

type Role = 'VENDOR' | 'CUSTOMER' | `RIDER`;

This provides same level of type safety, same intellisence, but less verbose and easier to use

Michael Mannseicher • Dec 11 • Edited

I would do it so

const ROLES = <const>['VENDOR','CUSTOMER' ,'RIDER'];
type Role = typeof ROLES[number];

Ishtiaq Mahmood Amin • Dec 10

Enums are horrible, considering the alternatives that typescript provides

Theo Ephraim • Dec 10 • Edited

Aside from the other issues mentioned, it's often very useful to use an object to store additional metadata that may be needed when using the options. You can use keyof typeof to extract the keys into a type (string union) to be used throughout your code.

For example:

const ANIMAL_DATA = Object.freeze({
  dog: { scientificName: 'Canis lupus familiaris' },
  cat: { scientificName: 'Felis catus' },
});

export type AnimalsEnum = keyof typeof ANIMAL_DATA; // 'dog' | 'cat'

Ravin Rau • Dec 10 • Edited

I used to use enum last time, but there were some issues that I faced.

increase in the size of the output
no proper type safety for string enums

Since then have been using plain object

const Role = {
    VENDOR: "Vendor",
    CUSTOMER: "Customer",
    RIDER: "Rider"
};

// Usage
console.log(Role. RIDER); // Output: Rider

Guilherme Taffarel Bergamin • Dec 11

Sometimes it's better to use Types for this kind of stuff because enums generate a lot of unnecessary transpired code (not a big issue if you don't have too many, tho) and because types will more easily resonate with people still using strings for this kind of stuff. It's still forcing everyone to use the correct string too.