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

61–70 of 217 posts

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

#61

Post by spankalee »

wk_end wrote: post #56
spankalee wrote: post #39

Earlier quoted context omitted.

What's the alternative? Have incorrect types for the function? That's not better.

To answer this we probably need more details, otherwise it's gonna be an XY Problem. What is it that I'm trying to do? How would I type this function in, say, SML, which isn't going to allow incorrect types but also doesn't allow these kinds of type gymnastics?

We don't have to deal in hypotheticals - we have a concrete example here. There's a method, array.flat() that does a thing that we can correctly describe in TypeScript's type system.

You say you would reject those correct types, but for what alternative?

It's hugely beneficial to library users to automatically get correctly type return values from functions without having to do error-prone casts. I would always take on the burden of correct types on the library side to improve the dev experience and reduce the risk of bugs on the library-consumption side.

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

#62

Post by ameliaquining »

NooneAtAll3 wrote: post #58
epolanski wrote: post #51

Earlier quoted context omitted.

The version I was thinking when I wrote the comment is simpler type Flatten = T extends Array ? Flatten : T > The average Typescript dev likely doesn't need to understand recursive conditional types. The average X dev in Y language doesn't need to understand Z is a poor argument in the context of writing better software.

as a person that never touched JS and TS... what's the difference between the two answers?

First one flattens a potentially-nested tuple type. E.g., FlatArr is [number, boolean, string].

Second one gets the element type of a potentially-nested array type. E.g., Flatten is number.

For what it's worth, I've never needed to use either of these, though I've occasionally had other uses for slightly fancy TypeScript type magic.

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

#63

Post by granzymes »

NooneAtAll3 wrote: post #58
epolanski wrote: post #51

Earlier quoted context omitted.

The version I was thinking when I wrote the comment is simpler type Flatten = T extends Array ? Flatten : T > The average Typescript dev likely doesn't need to understand recursive conditional types. The average X dev in Y language doesn't need to understand Z is a poor argument in the context of writing better software.

as a person that never touched JS and TS... what's the difference between the two answers?

For one, the simple answer is incomplete. It gives the fully unwrapped type of the array but you still need something like

  type FlatArray = Flatten[]
The main difference is that the first, rest logic in the complex version lets you maintain information TypeScript has about the length/positional types of the array. After flattening a 3-tuple of a number, boolean, and string array TypeScript can remember that the first index is a number, the second index is a boolean, and the remaining indices are strings. The second version of the type will give each index the type number | boolean | string.

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

#64

Post by monkpit »

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…

> ask someone to write a signature for array flat

Out of curiosity - what do you think is a satisfactory answer here?

My answer would vary wildly based upon more details, but at the most basic all I can think you could guarantee is Array => Array?

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

#65

Post by ameliaquining »

ibejoeb wrote: post #45
fourthark wrote: post #40

Earlier quoted context omitted.

It will get pattern matching when JS does. Not certain yet but in progress. https://github.com/tc39/proposal-pattern-matching

That proposal is really dragging though. And typescript needs as much work because that's where the real power is. We need discern thing like match (x) { "bob": ..., string: ..., () => Promise : ..., () => Promise : ..., } with exhaustiveness checking for it to be truly useful.

Discriminating a function or promise based on return type is never going to work, because JavaScript is dynamically typed and TypeScript erases types at compile time, so there's no way to know at runtime what type a function or promise is going to return.

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

#66

Post by ameliaquining »

nixpulvis wrote: post #57
reissbaker wrote: post #17

Earlier quoted context omitted.

The satisfies keyword is quite different than "as const." What it does is: 1. Enforce that a value adheres to a specific type 2. But, doesn't cause the value to be cast to that type. For example, if you have a Rect type like: type Rect = { w: number, h: number } You might want to enforce that some value satisfies Rect properties... But also allow it to have others. For example: const a = { x: 0, y: 0, w: 5, h: 5 }; I…

Why is satisfies needed at all, when can't. Typescript realize that `a` satisfies `Rect` automatically?

It does; the code will still type-check without the satisfies operator. satisfies lets you say "if this value doesn't conform to this type then I want that to be an immediate compile error, even if it would otherwise be okay". Which isn't needed all that often since usually getting the type wrong would produce a compile error elsewhere, but occasionally it proves useful. When designing the feature they collected some use cases: https://github.com/microsoft/TypeScript/issues/47920

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

#67

Post by furyofantares »

epolanski wrote: post #51
pcthrowaway wrote: post #22

Earlier quoted context omitted.

> Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. To be clear, an array flat type: type FlatArr = Arg extends [infer First, ...(infer Rest)] ? First extends unknown[] ? [...First, ...FlatArr ] : [First, ...FlatArr ] : []; is far from basic Typescript. The average Typescript dev likely doesn't need to understand recursive conditional types. It's a level of typescript one…

The version I was thinking when I wrote the comment is simpler type Flatten = T extends Array ? Flatten : T > The average Typescript dev likely doesn't need to understand recursive conditional types. The average X dev in Y language doesn't need to understand Z is a poor argument in the context of writing better software.

> The average X dev in Y language doesn't need to understand Z is a poor argument in the context of writing better software.

It's a good response to the claim that we'd be surprised at how many would fail to do this, though.

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

#68

Post by wk_end »

spankalee wrote: post #61
wk_end wrote: post #56

Earlier quoted context omitted.

To answer this we probably need more details, otherwise it's gonna be an XY Problem. What is it that I'm trying to do? How would I type this function in, say, SML, which isn't going to allow incorrect types but also doesn't allow these kinds of type gymnastics?

We don't have to deal in hypotheticals - we have a concrete example here. There's a method, array.flat() that does a thing that we can correctly describe in TypeScript's type system. You say you would reject those correct types, but for what alternative? It's hugely beneficial to library users to automatically get correctly type return values from functions without having to do error-prone casts. I would always take…

There's nothing I can do about the standard JavaScript library, but in terms of code I have influence over, I very simply would not write a difficult-to-type method like Array.prototype.flat(), if I could help it. That's what I mean by an XY Problem - why are we writing this difficult-to-type method in the first place and what can we do instead?

Let's suppose Array.prototype.flat() wasn't in the standard library, which is why I'm reviewing a PR with this gnarly type in it. If I went and asked you why you needed this, I guess you'd say the answer is: "because JavaScript lets me make heterogenous arrays, which lets me freely intermix elements and arrays and arrays of arrays and... in my arrays, and I'm doing that for something tree-like but also need to get an array of each element in the structure". To which I'd say something like "stop doing that, this isn't Lisp, define an actual data type for these things". Suddenly this typing problem goes away, because the type of your "flatten" method is just "MyStructure -> [MyElements]".

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

#69

Post by [deleted] »

nixpulvis wrote: post #57
reissbaker wrote: post #17

Earlier quoted context omitted.

The satisfies keyword is quite different than "as const." What it does is: 1. Enforce that a value adheres to a specific type 2. But, doesn't cause the value to be cast to that type. For example, if you have a Rect type like: type Rect = { w: number, h: number } You might want to enforce that some value satisfies Rect properties... But also allow it to have others. For example: const a = { x: 0, y: 0, w: 5, h: 5 }; I…

Why is satisfies needed at all, when can't. Typescript realize that `a` satisfies `Rect` automatically?

[deleted]

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

#70

Post by ethmarks »

Does anyone know what was used to render these code blocks in the article? The mouseover tooltip is extremely cool. I've never seen anything like it before.

EDIT: I dug through the codebase and determined that it's using Shiki and TwoSlash for the syntax highlighting and tooltips.

Post reply on HN