3 ms·
That’s the worst way to define enums. Now you have to make sure your codebase is using the same string literals everywhere and carry the potentially long type d
by ivan_gammel 2y ago
That’s the worst way to define enums. Now you have to make sure your codebase is using the same string literals everywhere and carry the potentially long type definition to every parameter, variable or function return type. And no, compile-time checks won’t cover 100% of cases.
- teaearlgraycold 2y agoObviously if this gets reused you need to put it in a central definition.
- SkyPuncher 2y agoThe only place I believe this pattern is acceptable is option props in React components. Otherwise, it becomes an absolute mess of “almost” defined correctly.
- ivan_gammel 2y agoHow wouldn’t it be reused? Besides, what will happen if you need to change a constant in the enum from „a“ to „b“? Compiler won’t help you to spot all the places like ˋˋˋif (value == „a“)ˋˋˋ, it will quietly become unreachable in runtime.
- teaearlgraycold 2y agoYou underestimate TypeScript. Your example will give a compiler error: This comparison appears to be unintentional because the types '"a"' and '"b"' have no overlap.(2367) https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAZiEAuGAiAhqmBeNmDcAUIQJZwwAUCIO2uqARqgJQwDehMXMokIANgFMAdPxABzChgCeIFkQC+hIA https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAZiEAu... It's features like these that make Python/Ruby/etc. type-checkers insufficient substitutes for TypeScript. I think my example wasn't the best. Of course "active" | "inactive" would get reused. But if it's just a little function flag it could easily be a one-off.