Hacker News Reader

Comment by ameliaquining | Hacker News Reader

Numeric enums are a lot more useful than string enums, in my view.

Just don't use numeric enums with implicit values. If you add a member anywhere but the end of the enum, it'll change existing members' values

I like string enums, since they are self-documenting, I guess int enums are smaller when sent over network. Could you expand on that?

Why do you find them self documenting?

Usually it's just

    enum Method {
      Get = "GET"
      // ...
    }

I usually always put doc comments on enums and their variants.

Regarding why numeric ones are (only sometimes) more useful than string values: bit flags comes to mind, faster comparison of numbers than strings (not always tho... unless this is a misconception, but I don't believe so), you mentioned smaller bundle size already.

As for "auto" enums: the fact they're numbers now is an implementation detail. They could be unique Symbols in a future versions of typescript. You can do that manually now too, but I'm talking about the automatic (without assignment) syntax.

Regarding article: I... Half-agree. But I'd not completely disregard/avoid enums. At the very least, they can be useful to help model some behaviours/states in more readable, accessible, and coherent way (Other comments went into a more in-depth defence of enums, thought).

   enum Method {
      Get = "method/GET"
      // ...
    }

The string value can be very helpful for the reader - be it a human or log ingestor

In the use cases where I most typically use enums, I don't want to think about the question of runtime representation; I just want a set of arbitrary symbols that are different from one another. Implicitly initialized numeric enums do this idiomatically and concisely.

Good point, I'm mostly doing web stuff so I always think about how something looks in JSON in the network panel of my browser.

If you just use the value within your code the runtime representation does not matter, you're completely right.

If you truly don't care about the runtime representation, then it sounds the idiomatic JS/TS construct you actually want is Symbol()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://www.typescriptlang.org/docs/handbook/2/everyday-type...

I agree that it might have been better for that to be the TypeScript idiom, but it's not, due to the longer-standing popularity and concision and language-level support for enums. (Which couldn't have originally been designed to be lowered to symbols, because at the time symbols weren't widely-supported enough.)

Symbols are very well supported in TS today. You even get proper type enforcement and intellisense when using symbols as the names of methods and properties, for instance. Whether you should use them for enum-like purposes or not has more to do with how you want to use the values though. For instance using symbols for defining numeric protocol values doesn't make sense. Same for HTTP methods, where you are always ultimately passing a string down to the http client/server interfaces

Symbol is an extremely heavy hammer. It's also difficult to use correctly.

What value do you think it offers here?

I brought up symbols because ameliaquining's declared requirements match symbols to a T:

> I don't want to think about the question of runtime representation; I just want a set of arbitrary symbols that are different from one another.

I wouldn't know how such requirements translate into value for her. Personally, when I need a set of type-checked fixed values, I favour string literal unions because a readable runtime representation eventually comes in handy.

The only time I recall using symbols was in order to have a "newtype"-like construct, which is a different thing entirely.

Could you expand on this? I can't think of places where a string enum would be less useful than a numeric, although I can think of places where numeric enums fall over, e.g. if you have a value that can be one of two different enums and you have to figure out which it is - runtime numeric enum values shouldn't be compared because they regularly have the same value.

Reply on news.ycombinator.com