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:

Solid Principles For Javascript

SOLID principles for JavaScript

SOLID principles help us keep code flexible. In this article, we’ll examine all of those principles and their implementation using JavaScript.

Frank Joseph
Dec 5, 2024 â‹… 10 min read
Master JavaScript Date And Time: From Moment.js To Temporal

Master JavaScript date and time: From Moment.js to Temporal

JavaScript’s Date API has many limitations. Explore alternative libraries like Moment.js, date-fns, and the new Temporal API.

Yan Sun
Dec 4, 2024 â‹… 9 min read
Npm Vs. Npx: What’s The Difference?

npm vs. npx: What’s the difference?

Explore use cases for using npm vs. npx such as long-term dependency management or temporary tasks and running packages on the fly.

Fimber Elemuwa
Dec 3, 2024 â‹… 5 min read
How To Audit And Validate AI-Generated Code Output

How to audit and validate AI-generated code output

Validating and auditing AI-generated code reduces code errors and ensures that code is compliant.

Boemo Mmopelwa
Dec 2, 2024 â‹… 5 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