[zogrodea]

My understanding of the comment is that it’s in the context of saving an enumeration-object into a database.

Like Typescript might (for example) represent enums as integers like 1, 2, 3... at runtime.

What happens if you decide to store a “delivery status” enum in a database? You would just be saving a number into the database, which can be hard to understand.

If it’s a string, then the value stored in the database is clearer and doesn’t depend on you being lucky with the Typescript compiler that the same enum type is compiled to the same integers after new releases.

I only realised this issue now, but it’s what I understood after reading that comment.

[CharlieDigital]

This is also another problem and a reason to strictly stick to string type unions, IMO.

There may be a really good use case for the enum type, but I think in most cases, string type unions are clearer, easier, and less prone to errors.

[yen223]

Yeah, one of the annoyances I have with using Enums, even in other languages, is that its serialised value isn't always obvious. Something like direction.NORTH could serialise into "NORTH" or some integer, depending on the language and the implementation.

I like Typescript's union of string literals approach because its serialised value is never in question. I know exactly what "NORTH" serialises to.

[ivan_gammel]

In Java it is de facto standard to serialize enums as string, with exception of JPA where you can explicitly tell if it’s a string or a number. It also supports exotic mappings via explicit declarations. Typescript should have implemented enums with union type under the hood, enabling the use of constants instead of strings when passing/checking values.