Stephen Gbolagade

Posted on Dec 10

TypeScript Best Practices — Using Enums

#javascript #typescript #webdev

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 debugging.

In enterprise software development, we often use Typescript to ensure our data is consistent.

But aside from using any to deceive ourselves (not the machine), we also ignore the importance of ENUMS.

Here is a scenario:

Your company is developing a food delivery software and you have 3 type of users who can sign up as demonstrated in the snippet below.

Someone in your team used Vendor, another person used vendor, you used VENDOR

That's a simple bug that can waste hours of productivity.

Solution:

Use ENUM to define the structure of your user Role. ENUM is readonly and very strict, it'll get your team members in order.

Code snippets

// Do ✅️
enum Role {
  Vendor = "VENDOR",
  Customer = "CUSTOMER",
  Rider = "RIDER"
}

const userRole: Role = Role.Admin;

// Don't ❌️
const userRole = "VENDOR"; // Very badd

// learn moteat www.stephengade.com

Top comments (12)

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.

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.