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

101–110 of 217 posts

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

#101

Post by Klaster_1 »

mckirk wrote: post #71
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 }

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.

Same here, you can also use the same function in switch cases in Angular templates for the same purpose. Had no idea you could achieve similar with `satisfies`, cool trick.

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

#102

Post by Defletter »

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.

Isn't that not necessarily out of the ordinary though? What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch? Or more likely, what if an update to a dynamic library adds another value to that enum (or whatever)? What some languages do is add an implicit default case. It's what Java does, at least: https://openjdk.org/jeps/361

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

#103

Post by triyambakam »

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.

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

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

#104

Post by atsjie »

hdjrudni wrote: post #46
miki123211 wrote: post #35

Earlier quoted context omitted.

I recently had to write a Promise.all, but using an object instead of an array. That was... non-trivial.

If it's what I'm thinking, that one isn't too bad. I wrote it awhile back: export async function promiseAll >>(promises: T): Promise }> { const keys = Object.keys(promises) as Array ; const result = await Promise.all(keys.map(key => promises[key])); return Object.fromEntries(result.map((value, i) => [keys[i], value])) as { [K in keyof T]: Awaited };

I'd call that bad pretty bad.

Without internet or AI I wouldn't attempt writing anything like that.

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

#105

Post by knallfrosch »

rvz wrote: post #82

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve; in many ways it’s the complete opposite of Go. Replace "TypeScript" with "C++" and the same can be said. It is one of the worst languages ever designed and already built on top of a sloppy foundation (Javascript) compared to Go. The language encourages escape hatches and tons of flexibility on how it checks its types…

Tell me when Go is browser ready

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

#106

Post by fragmede »

knallfrosch wrote: post #105
rvz wrote: post #82

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve; in many ways it’s the complete opposite of Go. Replace "TypeScript" with "C++" and the same can be said. It is one of the worst languages ever designed and already built on top of a sloppy foundation (Javascript) compared to Go. The language encourages escape hatches and tons of flexibility on how it checks its types…

Tell me when Go is browser ready

When.

    export GOOS=js
    export GOARCH=wasm

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

#107

Post by locknitpicker »

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.

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

The "impossibility" is just a trait of the type definitions and assertions that developers specify. You don't need to use TypeScript to understand that impossibilities written in by developers can and often are very possible.

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

#108

Post by rjh29 »

not_kurt_godel wrote: post #84
tomsmeding wrote: post #33

Earlier quoted context omitted.

Well, it is the type of that, in TS syntax. Few are the statically-typed languages that can even express that type.

Java: List Python: list[Any] ...what am I missing?

You're missing the specialisation of Object/Any. For example Array.flat called with [int, [bool, string]] returns a type [int, bool, string]. Admittedly this is somewhat niche, but most other languages can't express this - the type information gets erased.

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

#109

Post by rjh29 »

imiric wrote: post #36
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…

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.

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

#110

Post by locknitpicker »

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…

> 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.

I think you're both exaggerating your blanket accusations of incompetence and confusing learning curve with mastering extremely niche techniques akin to language gotchas.

Post reply on HN