Learning TypeScript and giving up on enums

When I first picked up TypeScript (in 2019? late to the party?) I was excited to dip my toes back into the world of statically typed languages. I had received a heavy dose of Java in school and some work. The code felt so clumsy and verbose that it left me resolutely anti-statically-typed-languages. In comparison, learning Python and then JavaScript was a breath of fresh air. I could convert ideas to code at such a faster rate than before that it spurred something like a Cambrian explosion of explorations and side-projects for me. Eventually, I dabbled in some other approaches to typed languages, e.g., Swift, GoLang, and Rust, and there was enough buzz around TypeScript that it seemed worth trying out.

Getting started

I started with their official docs, tried out writing something small, and had a friend who I could ping with questions.

Tools

I also knew I’d want to work in an IDE, so I installed VSCode. While I had happily used Emacs for JS and Python—it was what we used at MIT and what most of the programming team at Hunch worked in—I knew enough from my prior statically typed programming experiences that I’d need something that would provide all the completion, navigation, refactoring bells and whistles of an IDE. I also found an extension to keep using a lot of my usual keybindings.

I also really enjoy using Parcel to build front-end projects, so I generally relied on that to compile everything.

But enums?

Most concepts came fast enough, but the first one where I felt myself banging my head against the wall was with enums. I knew how to use enums in a number of other languages and thought to myself that it’d be a smarter way to handle code that previously would just be a couple variables assigned to strings or numbers. TypeScript has support for Enums. However, they just weren’t working how I expected, felt like they added a lot of complexity, and compile in complicated ways. I found myself Googling about how to use enums properly, but wasn’t finding the answers I was seeking. It smelled a lot like when you’re trying to fix a bug and you’re searching for answers, but coming up with nothing, only to find out your search queries were looking for entirely the thing.

In this case, it was unions. Instead of writing an enum like so:

enum Status {
  trialing,
  active,
  inactive,
}

You could just create a union like this:

type Status = 'trialing' | 'active' | 'inactive';

and now anything typed as Status will be one of those three strings and you can check against the type with simple equality comparisons (e.g., if (status === 'active') { … }).

This felt like such a violation of the DRY principle to be littering your codebase with string literals instead of a reference to a single variable. This aversion was making it hard for me to recognize that it was “the right way” to approach a lot of “enum” problems I was encountering. Furthermore:

1. It becomes way easier to manage in an IDE world, where code completion and warnings limit errors and speed up working with unions
2. It opens up other awesome features, such as Discriminated Unions, which impacts how to think about structuring data and makes typing with that data awesome!
3. Since we’re stuck with everything having to compile to JavaScript at the end of the day it can make sense why this “simpler” approach works

There are tons of write ups now on enums vs unions, but here’s one if you’re looking to dive a little deeper.