TypeScript Features to Avoid • Hacker News Board

Re: TypeScript Features to Avoid

#71

Post by ameliaquining » Thu, Jan 20, 2022, 2:07 PM UTC

leodriesch wrote: post #60

ameliaquining wrote: post #54

Earlier quoted context omitted.

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

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

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.

Re: TypeScript Features to Avoid

#72

Post by chrismorgan » Thu, Jan 20, 2022, 2:13 PM UTC

ameliaquining wrote: post #58

chrismorgan wrote: post #52

For people that don’t see the problem and are happily using these features, here’s an explanation of the second problem with these sorts of features, additional to the “it’s not just JavaScript with types which is what the label said” reason which is the focus of the article. The real trouble occurs when TypeScript implements something because that looks like the way things are heading, but then they don’t head that…

Did the other feature have anything to do with modules? If so, I can't really blame TypeScript too much for that, since the JavaScript ecosystem is pretty fragmented there and TypeScript has to support all the different things that are in use with a reasonable interop story. Build tools that work purely with JavaScript source code also have to deal with this problem. Otherwise I'm not aware of any cases besides decor…

I really don’t remember, sorry. I just scanned through https://github.com/Microsoft/TypeScript/wiki/Breaking-Change... and nothing jogged my memory; I’m wondering if it actually was something to do with decorators, though I still think probably not. I investigated a bit at the time because I was looking into using TypeScript on a certain project and the changes would probably affect me, but I wasn’t actually using TypeScript at the time, and it didn’t stick in my memory. Something about some change being spread over a few versions with deprecation followed by a silent breaking change in the generated code, but I can’t remember what.

Re: TypeScript Features to Avoid

#73

Post by ameliaquining » Thu, Jan 20, 2022, 2:16 PM UTC

activitypea wrote: post #55

ameliaquining wrote: post #49

This whole thing feels basically grounded in purity over practicality. In general it's a good idea to write idiomatic TypeScript. Even when I agree with the given recommendations, the given reasons don't seem like the strongest ones. I most strongly disagree with the recommendation against enums. Realistically, you will probably never run into a compiler bug from enum emit; maybe something like this might happen with…

> you will probably never run into a compiler bug from enum emit; That's true, but diagnosing other bugs is an absolute pain in the butt when your enum value at runtime is 0, 1, or 2. You get all of the readability of C with none of the performance :)

I personally haven't found that to be much of a hindrance to debugging, but I suppose this is somewhat a matter of personal preference.

Re: TypeScript Features to Avoid

#74

Post by mikojan » Thu, Jan 20, 2022, 2:18 PM UTC

fuzzy2 wrote: post #66

mikojan wrote: post #45

Earlier quoted context omitted.

That's precisely the problem. It makes the enum invisible to JavaScript users.

Yes, as it should be. There are no enums. Instead, you can pass in any of the documented strings (or whatever the base type is). Even inside TypeScript, an enum is really just a union type on steroids. When you expose TypeScript code to JavaScript consumers you absolutely must validate all incoming data anyway, whatever type you declare.

This is not about trusting the information your users provide. It is about making your APIs accessible to users. If you hide some information, your API is less accessible.

Re: TypeScript Features to Avoid

#75

Post by Tade0 » Thu, Jan 20, 2022, 2:30 PM UTC

I thought this is going to be about dependent types or the `infer` keyword(or any other badly documented feature like the latter).

There are features of the type system you should definitely avoid unless you're writing a library. Enums aren't it.

Re: TypeScript Features to Avoid

#76

Post by jacobr » Thu, Jan 20, 2022, 2:31 PM UTC

The TypeScript documentation even states "In modern TypeScript, you may not need an enum when an object with as const could suffice ... The biggest argument in favour of this format over TypeScript’s enum is that it keeps your codebase aligned with the state of JavaScript, and when/if enums are added to JavaScript then you can move to the additional syntax" https://www.typescriptlang.org/docs/handbook/enums.html#obje...

Re: TypeScript Features to Avoid

#77

Post by leodriesch » Thu, Jan 20, 2022, 2:35 PM UTC

ameliaquining wrote: post #71

leodriesch wrote: post #60

Earlier quoted context omitted.

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

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.

Re: TypeScript Features to Avoid

#78

Post by Vinnl » Thu, Jan 20, 2022, 2:36 PM UTC

donatj wrote: post #63

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript . There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript. If you ju…

> imho represent a misunderstanding of what Typescript is going for.

It's pretty what TypeScript's going for though:

> Avoid adding expression-level syntax.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Re: TypeScript Features to Avoid

#79

Post by fuzzy2 » Thu, Jan 20, 2022, 2:36 PM UTC

mikojan wrote: post #74

fuzzy2 wrote: post #66

Earlier quoted context omitted.

Yes, as it should be. There are no enums. Instead, you can pass in any of the documented strings (or whatever the base type is). Even inside TypeScript, an enum is really just a union type on steroids. When you expose TypeScript code to JavaScript consumers you absolutely must validate all incoming data anyway, whatever type you declare.

This is not about trusting the information your users provide. It is about making your APIs accessible to users. If you hide some information, your API is less accessible.

But it's just as hidden either way. The API consumer does not know there's an enum that's supposed to go in there. The only way to get that information is to read the documentation.

Re: TypeScript Features to Avoid

#80

Post by leodriesch » Thu, Jan 20, 2022, 2:40 PM UTC

a_humean wrote: post #68

antihero wrote: post #35

Earlier quoted context omitted.

esbuild seems to support enums fine

It doesn't support one variant of them, const enums for example. That ties you to tsc emit. Its pretty clear that if the tsc team could they would remove enums and favour literal unions.

I've just looked this up and it seems to support `const enum` just fine[0]. I remember Babel not being able to process `const enum`, since it goes across module boundaries and Babel does not.

[0]: https://github.com/evanw/esbuild/issues/128