2020-12-14
1057
#typescript
Paul Cowan
30575
Dec 14, 2020 â‹… 3 min read

Put the TypeScript enums and Booleans away

Paul Cowan Contract software developer.

Recent posts:

Glowing 3D cube with the MediaPipe and React logos overlaid, symbolizing integration of AI and web development

How to build better AI apps in React with MediaPipe’s latest APIs

Learn how to integrate MediaPipe’s Tasks API into a React app for fast, in-browser object detection using your webcam.

Emmanuel John
Jul 17, 2025 â‹… 10 min read
Vercel AI SDK logo on a 3D black grid background

How to build unified AI interfaces using the Vercel AI SDK

Integrating AI into modern frontend apps can be messy. This tutorial shows how the Vercel AI SDK simplifies it all, with streaming, multimodal input, and generative UI.

Ikeh Akinyemi
Jul 16, 2025 â‹… 13 min read
how to prepare for a software engineering interview

How to prep for a software dev interview: Advice from a dev leader

Interviewing for a software engineering role? Hear from a senior dev leader on what he looks for in candidates, and how to prepare yourself.

Andrew Evans
Jul 16, 2025 â‹… 12 min read
Next.js Real-Time Video Streaming: HLS.js And Alternatives

Next.js real-time video streaming: HLS.js and alternatives

Set up real-time video streaming in Next.js using HLS.js and alternatives, exploring integration, adaptive streaming, and token-based authentication.

Jude Miracle
Jul 15, 2025 â‹… 19 min read
View all posts

8 Replies to "Put the TypeScript enums and Booleans away"

  1. What about when you have a union of strings and you have strings fed into your app that implicitly acquire this string union but then you need to change one of the string values in your union?

    Now you get rogue errors from strings that no longer match the spec all throughout your app.

  2. You can also do algebraic data types and exhaustive pattern matching with enum values.

    {type:MyEnum.a} | {type:MyEnum.b} will work the same.

    I personally often prefer enums because you can search for usage of values, and rename them easily.

  3. Yes, I’m curious to know why the author did not conclude with that solution which is essentially the best of both world. As you said it’s much better for searching and refactoring and it’s the same behavior as using plain strings.

  4. It boils down to enums being references and strings being values. You can navigate through your code easily using enums. You can easily refactor them using code editor features like “rename symbol”. This for example does not work with strings. I’ve tested this with the example code you’ve linked in your comment.

    Also, you can define the value of “UnionSwitch[‘kind’]” with a simple variable: “const on = ‘on'” and use it inside an object of type “UnionSwitch”. This “on” variable however cannot be found using “go to references”. It’s like a blind spot. This however is not a problem with enums – unless you really want it to be.

  5. I think all of the replies so far have missed the point. I also mentioned booleans as a bad way of modelling state.

    The point is not about the string values and being able to refactor them, that seems hardly worthy of a post.

    The point is that enums like this

    enum Auth {
    unauthenticated = ‘unauthenticated’,
    authenticated = ‘authenticate,
    }

    or

    const isAuthenticated = true;
    const authenticated = false;

    are bad ways of modelling state and discriminated unions where the typescript compiler can type narrow on a string field is far superior:

    type Auth =
    | {
    kind: “UNAUTHORISED”;
    context: {
    isLoading: false
    };
    }
    | {
    kind: “AUTHENTICATING”;
    context: {
    isLoading: true;
    };
    }

    Unfortunately everyone seems fixated on the string values….that is a small point.

  6. all the replies so far have missed the point of the post and seem fixated on the string values, and the ease of refactoring string values.

    The point of the post is that booleans and enums are bad ways of modelling state.

    Modelling state is nothing to do with refactoring string values. That is not exactly worthy of a post.

    Discriminated unions are far superior and the example in the post has an authenticated state and the compiler only allows access to the authtoken field when it has type narrowed when the discriminator is of `kind: ‘Authenticated`

    refactoring string values is not exactly something to get excited about.

  7. I know what you want to say. And I agree, that discriminated unions are a far better idea to model the state than a simple interface. But you take two steps at the same time. You replace the initial state type or interface with a discriminated union AND you replace booleans or enums with a string. You make it seem that both go hand in hand or are the same thing, but those things are unrelated. I (and also others) suggest to only take the first step: Use DUs as the type of the state object but keep (mainly) enums for its properties:

    enum Auth { authenticated; unauthenticated }

    type AuthState =
    | { auth: Auth.unauthenticated }
    | { auth: Auth.authenticated, user: { username: string } }

    Olivier already made that example in a simpler form. Then you asked what this would give one aside from more code. And my answer was: Better flexibility and code analysis. And this is why it is – how Gabriel put it – the best of both worlds.

    So, yes. It is a small point. It is because we don’t fully disagree with what you say. We just want to provide a little improvement to your idea. The thing is, this small point is also the big message of the headline of this post.

Leave a Reply