4 ms·

I often find that types in typescript are bolted on and the whole thing gets pretty messy. I like typed languages like Java where the type system is more built

I often find that types in typescript are bolted on and the whole thing gets pretty messy. I like typed languages like Java where the type system is more built into the language. Typescript errors are also very annoying to read. This is TS code - and I think it's crazy. type DeepPartial<T> = { [P in keyof T]?: T[P] extends (infer U)[] ? DeepPartial<U>[] : T[P] extends ReadonlyArray<infer U> ? ReadonlyArray<DeepPartial<U>> : T[P] extends object ? DeepPartial<T[P]> : T[P]; };

digging 3y ago
Yes that's valid TypeScript, but is it good TypeScript? One should take a ternary nested that deep as a sign that refactoring is needed. You can write terrible code in any language, that doesn't make the language problematic.
- gardenhedge 3y ago
  Agreed that terrible code can show up in any language. For some reason, I notice it more with TS. Here's a random example too (not saying this is terrible, just confusing to me): https://github.com/prisma/prisma/blob/main/helpers/blaze/utils/types/Strict.ts https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...
- whoknowsidont 3y ago
  >Yes that's valid TypeScript, but is it good TypeScript? If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?
  - wk_end 3y ago
    Some combination of: * Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces. * ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility. * Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.
  - digging 3y ago
    I don't actually know off the top of my head how to refactor it - I've never had to write or deal with a type that complicated. It might actually be the best way of writing that specific type, in which case yes that kind of sucks, but I feel like it's probably not based on how hard it is to parse.
gsuuon 3y ago
But we can hide those utility types in a deep dark util.ts hole and never look at them ever again
acdha 3y ago
That’s not good TypeScript but I’ll note that I’ve seen a ton of nasty Java where everything is declared as taking “object”, and they’re abusing ternary operators just as badly (I remember this dude who had an allergy to if statements even if his ternararies wrapped into more lines), and lots of errors caught & ignored to avoid the “inconvenience” of handling them. This doesn’t mean that Java is a bad language, only that it can be used badly.
vlod 3y ago
If seen a lot of code like this and I f.hate it. Devs try and be too clever. With great power... etc Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy. However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison. Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness. The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler. I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).

digging 3y ago

Yes that's valid TypeScript, but is it good TypeScript? One should take a ternary nested that deep as a sign that refactoring is needed. You can write terrible code in any language, that doesn't make the language problematic.

gardenhedge 3y ago
Agreed that terrible code can show up in any language. For some reason, I notice it more with TS. Here's a random example too (not saying this is terrible, just confusing to me): https://github.com/prisma/prisma/blob/main/helpers/blaze/utils/types/Strict.ts https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...
whoknowsidont 3y ago
>Yes that's valid TypeScript, but is it good TypeScript? If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?
- wk_end 3y ago
  Some combination of: * Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces. * ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility. * Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.
- digging 3y ago
  I don't actually know off the top of my head how to refactor it - I've never had to write or deal with a type that complicated. It might actually be the best way of writing that specific type, in which case yes that kind of sucks, but I feel like it's probably not based on how hard it is to parse.

gsuuon 3y ago

But we can hide those utility types in a deep dark util.ts hole and never look at them ever again

acdha 3y ago

That’s not good TypeScript but I’ll note that I’ve seen a ton of nasty Java where everything is declared as taking “object”, and they’re abusing ternary operators just as badly (I remember this dude who had an allergy to if statements even if his ternararies wrapped into more lines), and lots of errors caught & ignored to avoid the “inconvenience” of handling them. This doesn’t mean that Java is a bad language, only that it can be used badly.

vlod 3y ago

If seen a lot of code like this and I f.hate it. Devs try and be too clever. With great power... etc Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy. However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison. Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness. The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler. I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).