10 ms·
Despite the large amount of criticism in the comments here I think that the point the article makes here is pretty valid. The described features are not what T
by leodriesch 5y ago
Despite the large amount of criticism in the comments here I think that the point the article makes here is pretty valid.
The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them.
IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So now that ESM can be used pretty much everywhere namespaces can be avoided and therefore reduce the learning surface of TypeScript.
Enums IMO have no advantage over union types with string literals, e.g. `type Status = 'fulfilled' | 'pending' | 'failed'`. They map way better to JSON and are generally easier to understand, while still benefiting from type safety and typo protection.
Well the private keyword is kind of like namespaces in that it came from a time where the feature was needed/wanted, but the EcmaScript spec was not moving fast enough. So they made their own version of it which is now obsolete.
And for decorators, IIRC the decorator spec has already moved on and TypeScript's implementation is no longer up to date with it. And the spec itself is only stage 2 as mentioned in the article, so I wouldn't recommend using decorators either, you will face breaking changes with them some time in the future.
Furthermore, it is far more likely that you run into trouble when using one of these features with a compiler that is not TSC, e.g. esbuild or Babel. Decorators have never been working all that well with the Babel plugin. Enums are probably fine here.
- ameliaquining 5y agoNumeric enums are a lot more useful than string enums, in my view.
- leodriesch 5y agoI like string enums, since they are self-documenting, I guess int enums are smaller when sent over network. Could you expand on that?
- spoiler 5y agoWhy 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).
- KuhlMensch 5y agoenum Method { Get = "method/GET" // ... } The string value can be very helpful for the reader - be it a human or log ingestor
- ameliaquining 5y agoIn 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.
- leodriesch 5y agoGood 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.
- piaste 5y agoIf 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/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#symbol https://www.typescriptlang.org/docs/handbook/2/everyday-type...
- ameliaquining 5y agoI 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.)
- rezonant 5y agoSymbols 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
- goodoldneon 5y agoJust 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
- CognitiveLens 5y agoCould 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.
- kesslern 5y agoOne advantage of enums is that you can iterate over all possible values of an enum, but not a union type.
- cobertos 5y agoYou can if you derive the union from a const array using indexed types. const MyTypeValues = ['a', 'b'] as const; type MyType = typeof MyTypeValues[number]; MyType is now a type 'a' | 'b'
- lucasyvas 5y agoThis is the way, because iterating enums produces odd results due to a bidirectional mapping. I had always used enums in TS until this year, but union literals are better. I create my own enums with const objects, compute the type based off the object's values. So very similar this, just with an object as the source instead of an array.
- sli 5y agoIterating over an enum in TypeScript always felt like code smell to me because of the filtering code I'd have to write to deal with the bidirectional mapping.
- jbbe 5y agoI often use that approach but (especially when you're importing from a seperate package) the compiler will sometimes view MyType as just an alias for string and won't catch typos. Am I missing something in how to use this?
- Recursing 5y ago`as const` is the important bit there, see this playground link https://www.typescriptlang.org/play?#code/MYewdgzgLgBKlQIICdkEMCeMC8MYG0BGAGgCZiBmAXRjQjnGgG4AoAGwFNY0AuGKDAAcOIAGYMEKdBnxgArgFsARh2Q1cAFiYwA9DpgAxNAEs2EFi3jQYYcAGFGsXETKUqrTrCV8BwsTftHWUUVNRwYLV19ABEQDggwAHJYURM2FiA https://www.typescriptlang.org/play?#code/MYewdgzgLgBKlQIICd...
- The_rationalist 5y ago
- iLoveOncall 5y ago> Enums IMO have no advantage over union types with string literals, e.g. `type Status = 'fulfilled' | 'pending' | 'failed'`. Well I would say having to not repeat and update your code everywhere when you change or add a possible value is a pretty big advantage.
- deleted 5y ago[deleted]
- Scarbutt 5y agoThough I have never seen anyone till now call TypeORM a fine choice.