Hacker News Reader

Comment by no_wizard | Hacker News Reader

I really wish the TS team would have used frozen null prototype objects for enums instead. Feels like it would have been a perfect fit.

With that said I am curious why you think one shouldn’t use enums. I know it’s a “factory” IIFE like namespaces at runtime but otherwise I don’t understand why it’s undesirable?

View on HN

My main issue with Enums in Typescript:

1. Because they have a runtime representation, I cannot do `import type` — and I am importing the entire file (which might have a side effect). While it's still not justified (ideally importing should not do anything) the reality in JavaScript is different.

2. I can swap the enum value with a number or a string and it would still work, even if invalid. See https://www.typescriptlang.org/play?#code/KYOwrgtgBAggxgFwJY... for an example

3. On the other hand, I cannot use strings to create an Enum (https://www.typescriptlang.org/play?#code/KYOwrgtgBAygLgJwJY...) — this is the exact opposite of n. 2

4. Duplicates are possible: https://www.typescriptlang.org/play?#code/KYOwrgtgBAIghgTwPI...

1. You can define enum like `const enum A {...}` and they will not have runtime representation.

Correct, but that does not solve the other issues I pointed.

Additionally, const enums DO NOT have an associated type. That is a problem in libraries, since users cannot reuse the type definition around (it back ports to a string or a number)

const enum doesn't work when in transpileOnly mode (e.g. webpack, Parcel), and Babel treats "const enum" the same as "enum". I'd really love a non-broken const enum in TypeScript, though.

I'd love to see them out of the language. I do not have evidence/document supporting this, but I think it was ultimately a failed attempt of copying the C# feature ignoring the fact that JavaScript works differently.

Why is #3 a problem? It's a feature! Enums are a great way to enforce values to a predefined set. I don't want you to work around it with random strings. Use the enum. That's what it is there for.

The biggest issue I have with enums is that unlikely virtually everything else in TypeScript, they are a "thing" (you correctly mentioned in your next comment that they don't have to be depending on their declaration, but that nuance will be lost on 99% of users). They're not just "types on top of JS", which defeats a lot of expectations in TypeScript. They're also not standard JS, so best practices with them aren't nearly as studied.

If they were to be part of the standard, it would be another story.

Yes. There are so few TS features that are non-type-level and non-standard. One option is to lint against these few features and call it a day.

  {
    "rules": {
      "no-restricted-syntax": [
        "error",
        {
          "selector": "TSEnumDeclaration",
          "message": "Enum restricted."
        },
        {
          "selector": "ClassDeclaration[abstract=true]",
          "message": "Abstract class restricted."
        },
        {
          "selector": "TSParameterProperty",
          "message": "Parameter property restricted."
        }
      ]
    }
  }

(TS decorators are already marked experimental)

Reply on news.ycombinator.com