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

Tricks I wish I knew when I learned TypeScript

cstrnt.dev

Post reply on HN
Print view View original

131–140 of 276 posts

Re: Tricks I wish I knew when I learned TypeScript

#131

Post by fidesomnes »

irrational wrote: post #127

Does Typescript get better? I've been forced to use it for my most recent project, but haven't been given any time to read through the documentation. I've found that I'm spending about 99.9999% of my development time trying to figure out how to get my IDE to not show that their are typescript problem. At this point I hate typescript with the burning fury of a trillion suns. I wonder if this is everyone else's experie…

if you don't understand objects and constructs you will hate it. if you do you will love it.

Re: Tricks I wish I knew when I learned TypeScript

#132

Post by dreamer7 »

jjice wrote: post #122

I'm so happy powerful type systems are more popular now. TypeScript bringing a great type system to a language as popular as JS is fantastic. Rust is also a great way to get a great type system while staying in a systems programming and procedural environment. Hell, even python type annotations support union types. I never knew the depth of type systems until the last year when I took a type theory course and a compi…

Could you point to any good resources on this topic?

Re: Tricks I wish I knew when I learned TypeScript

#133

Post by handrous »

irrational wrote: post #127

Does Typescript get better? I've been forced to use it for my most recent project, but haven't been given any time to read through the documentation. I've found that I'm spending about 99.9999% of my development time trying to figure out how to get my IDE to not show that their are typescript problem. At this point I hate typescript with the burning fury of a trillion suns. I wonder if this is everyone else's experie…

My experience is that the worst part is the config file. Its documentation isn't great and it's got a lot of cruft and overlapping functionality that can be confusing. It's easy to end up following a guide that's outdated or simply wrong in some subtle way that just happened to work for the original author but was still incorrect, when it comes to the config file.

Once it's set up, though, it's wonderful. No more refreshing only to discover you typo'd something or left out a step. You can hand your code to someone else—or to your future self—and they can often just start using it without having to ask questions, read documentation, or read the code to figure out what it does, because the types convey a ton of info and their editor/IDE presents it to them as-needed.

It lets you get your ideas about how the code works out "onto the page", as it were, and in a format in which a machine can automate most of the looking-up and finding-relevant-information-for-this-context parts. It slows down some code-writing a little (mostly by making you document things that should probably be documented anyway, either with tests [yes, tests are documentation] or in a manual or whatever) but speeds up using code so much that it more than makes up for the cost.

It's an incredible communication tool.

If you rarely need to communicate with others or with your future self about code you're writing, then it may not be worth using. So, if you're on a smallish solo project that you don't intend to stop working on until you're done working on it forever, never plan to hand to anyone else, and that you spend so much time working on that the whole thing's in your head nearly all the time, it might be fine to just write JS.

Re: Tricks I wish I knew when I learned TypeScript

#134

Post by irrational »

awestroke wrote: post #130
irrational wrote: post #127

Does Typescript get better? I've been forced to use it for my most recent project, but haven't been given any time to read through the documentation. I've found that I'm spending about 99.9999% of my development time trying to figure out how to get my IDE to not show that their are typescript problem. At this point I hate typescript with the burning fury of a trillion suns. I wonder if this is everyone else's experie…

Try fixing the problems

That is exactly what is taking 99.99+% of the development time. Fixing the problems with typescript. My JS code has no issues.

Re: Tricks I wish I knew when I learned TypeScript

#135

Post by jorisd »

alpha_squared wrote: post #119
skywal_l wrote: post #101

Earlier quoted context omitted.

type Ensure I define a type called Ensure This type takes two type parameters, one called T and the other K which will consist of Keys belonging to the type T (in our case, "foo", "bar" or "baz"). = T & This new type (called Ensure) will be equal to the union of two types: One will be T and the other will be: { [U in keyof Pick ] A new type which keys will be picked among the key listed in K -? To which we will remov…

This feels like considerable cognitive load for any developer that needs to work in more than one language.

Most of the implementation details here don't really matter until you need to modify these advanced types directly. That Ensure type definition line in that example is a low level detail that you put in a library somewhere, import throughout your codebase, and then mostly forget about.

In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the implementation to make it easier to modify later.

The TS compiler is surprisingly good at giving you good readable error messages as well when your code violates these advanced types; the errors tell you what you specified and what is supported, it doesn't display the low level type logic as part of the error users see. This means that there's very little need for anyone to really how these type definitions work.

EDIT: clarifications and spelling.

Re: Tricks I wish I knew when I learned TypeScript

#136

Post by zkldi »

errantspark wrote: post #107
handrous wrote: post #71

Earlier quoted context omitted.

> Everything that TS does JS libraries do better Which ones do you need to do everything TS does? > without the horrible tradeoffs Which tradeoffs are horrible?

Not OP but I do tend to avoid TS. I don't like the additional friction of working with the language (transpiling, unable to copy/paste directly into an interpreter). I also feel like the community at large writes awful baroque code that makes me want to die. Why use a function when 18 classes subclassing eachother across 4 files will do? If you're familiar with the tiktoker @khaby.lame, TS feels like exactly the over…

You can use `ts-node` to copy paste directly into an interpreter. (`npm/pnpm install -g ts-node`)

Re: Tricks I wish I knew when I learned TypeScript

#137

Post by alpha_squared »

jorisd wrote: post #135
alpha_squared wrote: post #119

Earlier quoted context omitted.

This feels like considerable cognitive load for any developer that needs to work in more than one language.

Most of the implementation details here don't really matter until you need to modify these advanced types directly. That Ensure type definition line in that example is a low level detail that you put in a library somewhere, import throughout your codebase, and then mostly forget about. In practice you'd have someone that understands this set it up once, and then document its usage for others, maybe document the imple…

Until it's the root cause of code not working as expected, by another developer far removed from initial implementation. Non-obvious code is harder to maintain. Code is written for people, not machines; that means the harder it is for people to maintain, the less useful it actually is.

Re: Tricks I wish I knew when I learned TypeScript

#138

Post by genezeta »

1penny42cents wrote: post #87

This is a nitpick; but the first example doesn't make sense once we use ReadOnly, because it doesn't return the copied+sorted array. So in practice the final version of sortNumbers would have no effect afaik.

The final version of sortNumbers is:

    function sortNumbers(array: Readonly>) {
      return [...array].sort((a, b) => a - b)
    }
And sort sorts in place and then returns the sorted array[0]. So here the newly created [...array] is sorted and then returned by sort and then by the return at the start of that line.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Tricks I wish I knew when I learned TypeScript

#139

Post by wdfx »

throwanem wrote: post #3

The third example describes something useful in record types, but goes about it in what seems an odd way, and ends up suboptimal as a result. I'd instead use an object type like this: type Human = { name: string; age: number; } which also enforces value types in the compiler, rather than requiring runtime guards.

The type itself is fine but how it is checked and used is not. The following would be better, and in this case you will also have a Human type inside the forEach callback:

    // ... other code

    type Human = { name: string; age: number }

    const isHuman = (obj: unknown): obj is Human => obj && typeof obj === 'object' && 'name' in obj && 'age' in obj; // you can complete the gaps here and also check the property types

    someArray.filter(isHuman).forEach((h) => {
      // h has type Human now
      console.log(h.age);
    })

Re: Tricks I wish I knew when I learned TypeScript

#140

Post by marginalia_nu »

jjice wrote: post #122

I'm so happy powerful type systems are more popular now. TypeScript bringing a great type system to a language as popular as JS is fantastic. Rust is also a great way to get a great type system while staying in a systems programming and procedural environment. Hell, even python type annotations support union types. I never knew the depth of type systems until the last year when I took a type theory course and a compi…

The grass does seem tend to appear greener in the other paradigm.

Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Writing anything nontrivial with duck typing made more elaborate type systems seem appealing.

Needing a PhD in category theory to produce a side effect will no doubt make some other paradigm seem appealing in the future.

Post reply on HN