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

41–50 of 217 posts

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

#41

Post by ibejoeb »

wk_end wrote: post #24
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…

If I saw that in a PR I would push very hard to reject; something like that is a maintenance burden that probably isn’t worth the cost, and I’ve been the most hardcore about types and TypeScript of anyone of any team I’ve been on in the past decade or so. Now, that said, I probably would want to be friends with that dev. Unless they had an AI generate it, in which case the sin is doubled.

If it's correct, it's not a maintenance nightmare, and it will alert you to problems later when someone wants to use it incorrectly.

If you're writing first-party software, it probably doesn't matter. But if you have consumers, it's important. The compiler will tell you what's wrong all downstream from there unless someone explicitly works around it. That's the one you want to reject.

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

#42

Post by Androider »

80% of the value of TypeScript is that it will tell you when when you changed or added a parameter and forgot to update it everywhere, you doofus. The other 20% is that it keeps coding agents from going too far off the rails. Trying to use the type system as a metaprogramming language is only valuable as a fun exercise, but of negative value in real world projects.

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

#43

Post by ervine »

IceDane wrote: post #32
madeofpalk wrote: post #29

Earlier quoted context omitted.

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

[flagged]

You can restructure your JS to avoid some crazy verbose TS though, sometimes. I think that's the point they were making. Why be so hostile?

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

#45

Post by ibejoeb »

fourthark wrote: post #40
lloydatkinson wrote: post #7

Earlier quoted context omitted.

TypeScript codebases I've seen generally seem to have the widest demonstration of skill gap versus other languages I use. For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse. For these developers, the `type` ke…

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.

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

#46

Post by hdjrudni »

miki123211 wrote: post #35
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…

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 };

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

#47

Post by preommr »

meh article

> Why is the name of person1 of type string and not the literal "Jerred"? Because the object could be mutated to contain any other string.

Not really, if you declare {name: "Jerred" as const}, it's still mutable. Typescript just decided that given certain primitive-like types like strings, it's preferrable to infer string rather than as constant.

Satisfies offers the opposite AS A MOSTLY ORTHOGONAL design decision. It's a happy byproduct that the type inference's behavior is changed.

And this is relevant because it affects technically important situations like deeply nested values NOT being narrowed, but it's also just not a good mental model for what it's supposed to do.

People should assume that given a type literal, that it just infers the widest typing. Incidental behavior that arises from using 'as const', or 'satisfies' should follow it's semantic purpose. If you want specific typing, just build the type - don't use hacks.

Satisfies is useful because sometimes you have something with some typing (often as const for something like utils), that you also need to make sure satisfies some other typing - almost as a constraint.

Would not surprise me if ts team released a keyword that did type inference with narrowest (like as const, but without the readonly).

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

#49

Post by dzonga »

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…

typescript is largely a result of solving a non-existent problem. Yeah JS is finicky & has foot-guns, however they're ways around those foot guns that don't involve typescript.

Rich Hickey in 10 Years of Clojure & Maybe Not then the Value of Values - lays this out - though not meant at typescript but static types in general.

the thing most people don't have proper Javascript fundamentals.

Function signatures: JSDoc works

Most types - use Maps | Arrays

if a value doesn't exist in a map we can ignore it. There's also the safe navigation operator.

Instead of mutable objects - there's ways around this too. Negating types again.

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

#50

Post by inlined »

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 }

Nice. I didn’t know I can now replace my “assertExhaustive” function.

Previously you could define a function that accepted never and throws. It tells the compiler that you expect the code path to be exhaustive and fixes any return value expected errors. If the type is changed so that it’s no longer exhaustive it will fail to compile and (still better than satisfies) if an invalid value is passed at runtime it will throw.

Post reply on HN