Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript Features to Avoid

executeprogram.com

Post reply on HN
Print view View original

201–210 of 212 posts

Re: TypeScript Features to Avoid

#201

Post by ragnese »

nfw2 wrote: post #174
ragnese wrote: post #144

Earlier quoted context omitted.

So... You have two declarations, one of which is a real array that's allocated at runtime. Is that really better than an enum? Not to mention, there's a slight mental overhead to parsing this. When I see this code, I might wonder if there's a reason for this to be an array. I might wonder if the order is intentional. An enum has a more clear intent. My only complaint is that enums are not string-by-default, so we end…

One minor advantage is that you can import the type on its own. If an external app just needs the types, it can import them without affecting its bundle at all.

Fair point.

Re: TypeScript Features to Avoid

#202

Post by captainmuon »

I think the attitude that they show in #1 - that TypeScript is only supposed to add typing to JavaScript and everything that goes beyond is bad - is wrong.

In fact, the only major problem I have with TypeScript is the lack of operator overloading [1]. This feature has been denied with the exact same justification. They will not add any feature that emits additional logic, so they cannot add operator overloading unless JS adds it. Also they will not add anything that needs runtime type lookup.

I think very simple, stupid syntactic sugar would be sufficient to solve 90% of use cases. For example, and please don't take this apart, I'm just making it up on the spot: transforming `a + b` to `a._op_add(b)` if a is not provably `any` or a primitive type.

Without operator overloading, for example vector math looks really ugly. I hope somebody will make at least a babel plugin or something to allow that.

[1]: https://github.com/microsoft/TypeScript/issues/6936

Re: TypeScript Features to Avoid

#203

Post by mikojan »

fuzzy2 wrote: post #79
mikojan wrote: post #74

Earlier quoted context omitted.

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.

I have no idea where you are coming from unfortunately.

Generally speaking, a Javascript user has access to the same type script language features (including hints, auto-completion,...) as a typescript user.

Even the most primitive text editor supports language server protocol nowadays.

The library your interoperating with does not even have to be written in typescript if the author provided @typedef JSDocs.

const enums break this because no value of this type exists

Re: TypeScript Features to Avoid

#204

Post by Izkata »

ragnese wrote: post #165
JohnHaugeland wrote: post #159

Earlier quoted context omitted.

> Is that really better than an enum? Substantially. Look at the generated code for an enum. Also, this approach does not suffer the problems described by the article.

> Substantially. Look at the generated code for an enum. I'll give you that. It looks like the TS compiler (according to the playground site) spits out some code that's intended for maximum compatibility with older versions of JS, even when targeting newer versions (which makes sense, since nothing is technically wrong about it). It spits out: "use strict"; var MyType; (function (MyType) { MyType["A"] = "a"; MyType["…

The modern Javascript version of that would be the same as the compiled Typescript version, the const version doesn't do the same things.

The IIFE is creating an object only if it doesn't already exist, and adds "A" and "B" to it. "var" doesn't error on a redeclaration, so if MyType already existed you'll get a mashup of the two versions of it. Even if the const was switched to var in the second one, that would still be a straight replacement of the values instead of merging them.

I haven't used Typescript, but I imagine this style was used so enums could gain new values later in the code without having to worry about execution order.

Re: TypeScript Features to Avoid

#205

Post by ragnese »

Izkata wrote: post #204
ragnese wrote: post #165

Earlier quoted context omitted.

> Substantially. Look at the generated code for an enum. I'll give you that. It looks like the TS compiler (according to the playground site) spits out some code that's intended for maximum compatibility with older versions of JS, even when targeting newer versions (which makes sense, since nothing is technically wrong about it). It spits out: "use strict"; var MyType; (function (MyType) { MyType["A"] = "a"; MyType["…

The modern Javascript version of that would be the same as the compiled Typescript version, the const version doesn't do the same things. The IIFE is creating an object only if it doesn't already exist, and adds "A" and "B" to it. "var" doesn't error on a redeclaration, so if MyType already existed you'll get a mashup of the two versions of it. Even if the const was switched to var in the second one, that would still…

Oh, good point. I forgot about var not getting mad at redeclaration. So the default TS implementation will merge an existing object with the newly defined fields. I'm too lazy to check, but I wonder what happens if MyType already exists and is a scalar, like a number...

I think I was still accidentally correct in saying that's what we'd write because who the hell actually WANTS the default behavior? :p

Re: TypeScript Features to Avoid

#206

Post by eyelidlessness »

erikpukinskis wrote: post #196
eyelidlessness wrote: post #110

The reason enums are useful—and the private keyword until recently with JS adding private fields—are that they’re nominal types. You can have… enum HTTPMethod { POST = 'post', // ... } enum FenceMaterial { POST = 'post', // ... } … and you can be sure 'post' is not ambiguous. Private fields have the same benefit, which is particularly useful for treating abstract classes as nominal interfaces. But yes, if your target…

This is actually the reason I prefer string unions. Lets say I have a function that converts sizes to pixels: const sizeToPx(size: ‘small’ | ‘med’ | ‘large’): number If I have a Button component that can only be small or medium that’s no problem: type ButtonProps = { size: ‘small’ | ‘medium’ } const Button = styled.button(({ size }: ButtonProps) => ({ height: sizeToPx(size) I can’t do that with an enum. You’re correc…

You can do that with an enum!

  enum Size {
    small = 'small',
    medium = 'medium',
    large = 'large',
  }

  type ButtonProps = { size: Size.small | Size.medium }
And it’s still a nominal type in the union.

Regarding likelihood of collision, it’s easy for me to imagine mixing up 'post' in an API call to a vendor for fence materials lol. In any case I find the added safety comforting, particularly over a language where interfaces tend to be exceedingly dynamic and flexible.

Re: TypeScript Features to Avoid

#207

Post by crabmusket »

yawaramin wrote: post #188
crabmusket wrote: post #177

> We recommend the new #somePrivateField syntax for a straightforward reason: these two features are roughly equivalent. The author of the article surely knows the significant difference between JS private fields and TS private fields: TS private fields can be easily circumvented, whereas JS private fields cannot. See TS playground link[1] I think this is a significant enough point that people should not be taught th…

I mean if you look at it like that, then yeah sure anything in TypeScript can ultimately be circumvented. Just like `unsafe` in Rust or `unsafePerformIO` in Haskell. The point is that we as developers choose to respect the typechecker.

Rust's `unsafe` can't do anything and nor can `unsafePerformIO`. There seems to be no way to break into #private fields, unless I've missed something. So I think the difference is significant.

I'm not saying that TS being a "fancy linter" is a bad thing - I actually think quite the opposite.

Re: TypeScript Features to Avoid

#208

Post by rezonant »

mhoad wrote: post #197
rezonant wrote: post #192

Earlier quoted context omitted.

> respective accessibility APIs that each platform exposes. That's the problem, there isnt an accessibility API for the web, is there? EDIT: At least not one that works without DOM

Hence my timeline of a few years, right now browsers have coupled accessibility with the DOM but that is going to change.

Well I do hope so. So far I'm unaware of any pending proposals in the standards tracks :-/

Re: TypeScript Features to Avoid

#210

Post by paleite »

dmarchuk wrote: post #34
wdb wrote: post #12

Earlier quoted context omitted.

I wish TypeScript somehow would use #-private fields underwater when compiling code. `#field` is pretty confusing; I keep thinking it's a comment and it looks ugly

Although I do understand the reasoning in the article, I completely agree with you. Switching between Python and TypeScript/JavaScript all the time, using ‘#’ to define private field feels weird and I personally prefer more explicit way of writing code. Plus AFAIK the ‘private someField’ is common in other languages (Java, Scala,…).

Couldn’t agree more!

Explain the differences in the following to a new developer:

something - a regular variable

$something - just another regular variable with a fancy char

#something - now that’s a private variable

!something - this is… uhm… a regular variable cast to… eh… boolean, then inverted…

~something - type cast blah blah bit flipping magic

!!something - same as !something except inverted again, because using Boolean(something) is not 1337

//something - a comment

Yeah… personally, I much prefer the more explicit ways to write code. it’s cryptic enough as it is, why make it harder for your peers

Post reply on HN