4 ms·
Ah I love Typescript (IMO JS is the best "scripting language" out there, and has been for a very long time, but that's a different discussion). That said, I ha
by hardwaresofton 2y ago
Ah I love Typescript (IMO JS is the best "scripting language" out there, and has been for a very long time, but that's a different discussion).
That said, I hate that typescript has many ways of doing it. That's the biggest problem.
There's:
enum SomeEnum {
First,
Second,
}
const enum SomeConstEnum {
A = 1,
B = A * 2,
}
type SomeEnumType = "first" | "second";
const SomeObjectThatIsAnEnum = {
"first": 1
"second": 2
} as const
I always lean towards the `enum` keyword, because I am of the opinion that if you're optimizing for less generated JS (and enums are actually worth optimizing for in this way) you're probably using the wrong language to begin with (unless you're in the browser and have no choice, etc).
- ikekkdcjkfke 2y agoTypescript type system is probably gold standard, you can enforce so much statically
- hardwaresofton 2y agoAs far as gold standards go for typesystems... ML languages probably take it, with Haskell being the closest to widespread real world use.
- teaearlgraycold 2y agoIt's the gold standard for languages you'll be able to use at work.
- CharlieDigital 2y agoTypeScript enums, from personal experience, should be avoided in cases where the value is stored. The reason is that the compilation from `SomeEnum` to JS involves conversion to an object indexer[0]. Should you, in the future, need to (or accidentally) remove or change an enum option, this will fail with an index out of range exception at runtime that is not obvious to track down. Put it another way: it leaves behind an artifact in the output JS that can be a source of exceptions. [0] https://www.typescriptlang.org/play/?ssl=5&ssc=2&pln=1&pc=1#code/KYOwrgtgBAwg9gGzgJwM5QN4Cgq6gJWABMAaHPAcWWFDLygCEExgsBfIA https://www.typescriptlang.org/play/?ssl=5&ssc=2&pln=1&pc=1#...
- hardwaresofton 2y agoSorry, can you explain this more? I somehow still don't understand. How is this different from a const object style enum? Or are you more referring to the sum type enum as the better choice here to avoid this. Generally, if you remove an enum variant, the compiler should warn you if you've used it anywhere else (though of course it can't figure out a dynamic usage)... But this seems like a problem mostly for dynamic code, where you'd probably write some sort of Enum.parse() or Enum.from() static method anyway? If I'm understanding your comment correctly, the real problem is that when you store the value, remove one, and try to read it back out into the enum it will fail - but in the code I've written so far trying to construct the the enum object almost always consisted of using a function to validate anyway, these days I use zod but before I'd write stuff like: function isEnum(obj: unknown): obj is Enum { return obj && typeof obj === 'string' && Object.values(Enum).includes(obj) }
- zogrodea 2y agoMy 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 2y agoThis 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 2y agoYeah, 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.
- c-hendricks 2y agoI've done things like this before: https://www.typescriptlang.org/play/?#code/PTAEAkFMBsAdIE4GcB0AoALgT3qAggggIZYCSGkAtgCo6QA81AfKALyjWiQAeFAdgBMkoAEqQiAgPZ9oWAsSz0AlnwBmiUAGkWAfi2gAXBy69Ig4fJLK1G7aD2bDoAK58A1n0kB3PmjSrXAGMMJWlQIiQkRAwAUT5nSgA1ImhnBk4efiFRcSkZOUIrVw9vPiYmAAoANxS0o2LPHwAaUBrUyCQjagBKIwiohAxhNrTQJWFOAG80UFmx1VAKgEIRjpQVQNSBDurayG7u0Gm5k9AMAAsEb1A+SC9QGMJJBAqAAwASSdWkAF9QKQ6N0kGDGfE2zm2oE+qx+r26MzmPzQSP8QRCYXGcQSyXajBMWWEYgk0lklkUDVK5V27Xq7kafBa3y6vVaezGEyOCNmCEgGGcCD4rPaqA2Wx2q3hKJAoAAIpBVCpIKAsJJ+Vx4pR0IFpEgQZQsABlDAIFQAcyxlDYoAA2gByIi2lq2gBGjtAtsCtoAuuFhNq+LrMHRQABZQ3Gs0Wq1k8hUWjwejYeCSBb6o0mvjmjVMPwBMHowV54KhPgAVSQZrD6cjGoqRAQpqMVYjmYth2Oc39SEk0EgKGgklNdYbkr8Xb1WAAcglnYgo+xrQAGFoARhaACYfRFQOOg7gw9PKLOEPP8IUyBQaHRE3QU6B9Yfjxac6j8yXQEWC+XK1OZ3Pa-Wjahr+R7-gk7ZcjuOo9n2A5DoBo5oNKADizj1gI-xUJI6DGlgnInP00QWjiaQVLaAhummLZZuByI7kQGCBOc+GdtBvb9oOZE8PAwSQBRiFKAsFSYhqJGQGRnotFRGY0ZQBwsbMXYwRxQ62txkC8fxyJ+NKBrnKq0AYbOoCSG46CfiW36Zs2MkWmRDrwrp+nOIZoBePWfDmWilkVtZ4a2bW5G2vCSFgHpBlGUqpleW+0hWaaB5-ietaLo5YXOa57kCjFxZxb5CUgU+tYAMzwkAA https://www.typescriptlang.org/play/?#code/PTAEAkFMBsAdIE4Gc... The gist is: define your enum values as a const array. Then you can generate a TypeScript type based on whatever values you have in there. And, since it's an actual array, you can easily write guards / asserts. So you end up with something easy to extend and also has compile-time and run-time checks.
- hardwaresofton 2y agoThanks for the snippet, it is INTENSE. Will see what I can learn from it — const array I definitely didn’t consider before!