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

`satisfies` is my favorite TypeScript keyword (2024)

sjer.red

Post reply on HN
Print view View original

131–140 of 217 posts

Re: `satisfies` is my favorite TypeScript keyword (2024)

#131

Post by IshKebab »

madeofpalk wrote: post #29
epolanski wrote: post #3

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…

> Too many really stop at the very basics. As someone who knows slightly more than the basics, and enough to know about the advanced stuff that I don't know about, this is the correct place to stop. I would much rather restructure my javascript than do typescript gymnastics to fit it into the type system.

I agree. The advanced stuff mostly exists in order to allow writing type annotations for JavaScript libraries that have APIs that are very dynamic.

If you're purely writing Typescript then you mostly don't need it.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#132

Post by klinch »

amake wrote: post #48

99% of my use of `satisfies` is to type-check exhaustivity in `switch` statements: type Foo = 'foo' | 'bar'; const myFoo: Foo = 'foo'; switch (myFoo) { case 'foo': // do stuff break; default: myFoo satisfies never; // Error here because 'bar' not handled }

TIL.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#133

Post by samdoesnothing »

kennywinker wrote: post #124
samdoesnothing wrote: post #99

Earlier quoted context omitted.

How would you convert a Number type to a ClampedNumber type without casting?

Ah, yeah you’re right. I somehow thought typescript could do type narrowing based on checks - like say: If (i >= 1) { // i’s type now includes >= 1 } But that is not the case, so you’d need a single cast to make it work (from number to ClampedNumber ) or however exactly you’d want to express this. Tbf having looked more closely into how typescript handles number range types, I don’t think I would ever use them. Not v…

How would you implement it in other languages that support it better? Can you literally just do a range check and the compiler infers its range for types? If so thats actually pretty neat.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#134

Post by jaapz »

jstanley wrote: post #98
mckirk wrote: post #71

Earlier quoted context omitted.

I generally do this via a `throw UnsupportedValueError(value)`, where the exception constructor only accepts a `never`. That way I have both a compile time check as well as an error at runtime, if anything weird happens and there's an unexpected value.

The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript.

It's way better than having to write untyped JavaScript though

Re: `satisfies` is my favorite TypeScript keyword (2024)

#135

Post by eitland »

jstanley wrote: post #98
mckirk wrote: post #71

Earlier quoted context omitted.

I generally do this via a `throw UnsupportedValueError(value)`, where the exception constructor only accepts a `never`. That way I have both a compile time check as well as an error at runtime, if anything weird happens and there's an unexpected value.

The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript.

TypeScript isn't primarily meant to be enjoyed.

It is meant to be a much better alternative to Javascript while dealing with the fact that the underlying engines use and existing programmers were used to Javascript.

That said I absolutely enjoy TypeScript, but that might be because I suffered from having to deal with Javascript from 2006 until TypeScript became available.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#136

Post by imiric »

rjh29 wrote: post #109
imiric wrote: post #36

Earlier quoted context omitted.

You're right, but that begs the question: does a type system really require such complexity? I'm aware that type theory is a field in and of itself, with a lot of history and breadth, but do developers really need deep levels of type flexibility for a language to be useful and for the compiler to be helpful? I think TypeScript encourages "overtyping" to the detriment of legibility and comprehension, even though it is…

The idea is to make libraries preserve as much type information as possible, as a principle. Once type information is erased it can't be restored. For regular application code you don't need to use those features.

But regular application code also contains libraries. Type information is useful even if you're the only user of those APIs.

My point was more related to the level of expressiveness required of a type system in order to allow a programmer to produce reliable code without getting in their way. I think TypeScript leans more towards cumbersome than useful.

For example, I'm more familiar with Go's type system, which is on the other side of that scale. It is certainly much less expressive and powerful than TypeScript, and I have found it frustrating and limiting in many ways, but in most day-to-day scenarios it's reasonably adequate. Are Go programs inherently worse off than TypeScript programs? Does a Go programmer have a worse experience overall? I would say: no.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#137

Post by virtue3 »

eitland wrote: post #135
jstanley wrote: post #98

Earlier quoted context omitted.

The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript.

TypeScript isn't primarily meant to be enjoyed. It is meant to be a much better alternative to Javascript while dealing with the fact that the underlying engines use and existing programmers were used to Javascript. That said I absolutely enjoy TypeScript, but that might be because I suffered from having to deal with Javascript from 2006 until TypeScript became available.

I have the exact same reason I enjoy typescript - raw dogging js before was an absolute nightmare of testing every single function for every possible value that might be thrown in and being able to handle shit data everywhere.

god-awful code.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#138

Post by stgr_codes »

This article shows the kind of overthinking that I hate when it comes to typescript usage. This is also the reason why I'm falling in love with Go.

Don't get me started on how this is so unnecessary on the browser (so the utility on this kind of stuff is actually for library development; maybe).

Am I the only one that thinks that Typescript waste your time on minutia like this?

Re: `satisfies` is my favorite TypeScript keyword (2024)

#139

Post by MrJohz »

another_twist wrote: post #121
ibejoeb wrote: post #54

Earlier quoted context omitted.

The author gets into that. `Thetype` might be complex. It also protects you from overgeneralizing, like casting to and from `unknown` to escape the type checker. type Current = { kind: "ac" | "dc"; amps: number; } type Dc = { kind: "dc"; amps: number; } const ac: Current = { kind: "ac", amps: 10000000, } const handleDc = (thing: Dc) => {} const badConvert = (c: Current) => ({...c, kind: "dc"}); /** * Argument of type…

The bad convert is actually wrong. It should be refactored to an equality check and throw an error if account kind is not "dc". The compiler is correct and its not a good idea to work around this issue.

No, the point of the function is to convert the type. It doesn't need to check anything, it just forcibly converts any argument to DC.

The compiler isn't complaining because the conversion isn't valid, it's complaining because it doesn't know that the string "dc" should be narrowed down to a literal type, and so it's kept it as broad as possible. Using `satisfies` lets it understand that it needs to do narrowing here.

In fairness I don't think this is the best case for `satisfies`, and some return type annotations would probably work a lot better here, and be clearer to read.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#140

Post by LordN00b »

debugnik wrote: post #111
triyambakam wrote: post #103

Earlier quoted context omitted.

That scenario is usually either misuse of escape hatches (especially at API boundaries) or a misunderstanding of what Typescript actually guarantees.

Not really, I provided these examples a couple weeks ago on another HN thread. TypeScript is simply unsound. https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAllApg... https://www.typescriptlang.org/play/?#code/DYUwLgBAHgXBB2BXA...

In the first example you deliberately create an ambiguous type, when you already know that it's not. You told the compiler you know more than it does. The second is a delegate, that will be triggered at any point during runtime. How can the compiler know what x will be?
Post reply on HN