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

191–200 of 217 posts

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

#191

Post by plaguuuuuu »

shortrounddev2 wrote: post #163
swiftcoder wrote: post #153

Earlier quoted context omitted.

> 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 As someone who came from a CS background, this kind of attitude is deeply mysterious. That seems like a type expression I'd expect a CS undergrad to be able to write - certainly if an SDE with 1-2 years experience was confused by it, I'd be advocating against their further promotion…

The every day practice of software engineering has little to do with the academic discipline of computer science. What makes a good software engineer is not usually the same thing that makes a good CS major

but then you wind up with an entire repo, or an entire engineering team utterly hobbled by a lack of expressive typing (or advanced concepts generally) and debased by the inelegance of basic bitch programming.

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

#192

Post by locknitpicker »

samdoesnothing wrote: post #92
kennywinker wrote: post #91

Earlier quoted context omitted.

For a function setVelocity() that can accept 1.. Btw, using “autism” to mean “pedantry” leaves a bit of a bad taste in my mouth. Maybe you could reconsider using it that way in the future.

Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data. You could just clamp velocity to 200 in the callee and save all that hassle.

> Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data.

TypeScript does not perform any kind of casting at all. What TypeScript supports is structural typing, which boils down to allowing developers to specify type hints in a way that allows the TypeScript compiler to determine which properties or invariants are met in specific code paths.

Literal types address a very common and very mundane use case: assert what can and cannot be done with an object depending on what value one of it's fields have.

Take for example authorization headers. When they are set, their prefix tells you which authorization scheme is being used by clients. With typescript you can express those strings as a prefix constrained string type, and use them to have the TypeScript compiler prevent you from accidentally pass bearer tokens to the function that handles basic authentication.

Literal types shine when you are using them to specify discriminant fields in different types. Say for example you have a JSON object that has a `version` field. With literal types you can define different types discriminated by what string value features in it's `version` field, and based on that alone you can implement fully type-safe code paths.

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

#193

Post by ibejoeb »

nrhrjrjrjtntbt wrote: post #74
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…

I see. I dont mind this use case as much. It is like a hint.

Exactly. It's a safer assertion, as the author points out. You can work without it, but it's a little more cumbersome and involves creating the otherwise unnecessary, transient intermediate types.

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

#194

Post by swiftcoder »

shortrounddev2 wrote: post #163
swiftcoder wrote: post #153

Earlier quoted context omitted.

> 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 As someone who came from a CS background, this kind of attitude is deeply mysterious. That seems like a type expression I'd expect a CS undergrad to be able to write - certainly if an SDE with 1-2 years experience was confused by it, I'd be advocating against their further promotion…

The every day practice of software engineering has little to do with the academic discipline of computer science. What makes a good software engineer is not usually the same thing that makes a good CS major

Sure, but basic CS knowledge is an expectation in much of the software field (albeit less since the mid-2010's javascript boom). A lot of companies aren't going to hire you if you don't know the basics of data structures and algorithms

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

#195

Post by swiftcoder »

locknitpicker wrote: post #174
swiftcoder wrote: post #149

Earlier quoted context omitted.

> No tool is perfect. What matters is if a tool is useful Some tools are more perfect and more useful than others. Typescript's type system is very powerful, but without strict compile-time enforcement you still spend a lot of effort on validating runtime weirdness (that the compiler ought to be able to enforce).

> Typescript's type system is very powerful, but without strict compile-time enforcement you still spend a lot of effort on validating runtime weirdness (that the compiler ought to be able to enforce). That's something that you own and control, though. Just because TypeScript allows developers to gently onboard static type checking by disabling or watering down checks, that does not mean TypeScipt is the reason you s…

> Just because TypeScript allows developers... does not mean TypeScipt is the reason you spend time validating your own bugs

Unfortunately, taking an ecosystem-wide view, it means exactly that. If one of my dependencies hasn't provided type stubs, or has provided stubs, but then violated their own type signatures in some way, I'm on the hook for the outputs not matching the type annotations.

In a strict language, The compiler would assert that the dependency's declared types matched their code, and I'd only be on the hook for type violations in my own code.

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

#196

Post by ibejoeb »

ameliaquining wrote: post #65
ibejoeb wrote: post #45

Earlier quoted context omitted.

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.

It'll work because that's what typescript does, and that's why it needs to be implemented there, also. That's my point.

And as far as runtime goes, well, that's not what typescript does. It's a typical compile-time static type system.

Typescript aside, even a javascript-level first-class pattern expression is still extremely useful. I really hope it gets in there soon.

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

#197

Post by ibejoeb »

locknitpicker wrote: post #112
ibejoeb wrote: post #41

Earlier quoted context omitted.

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.

> 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. You're confusing things. It is a maintenance nightmare because it is your job to ensure it is correct and remains correct in spite of changes. You are the one owning that mess and held accountable for it. > If you're writing first-party software, it probably doesn't matter. But if you…

> Whoever feels compelled to write unintelligible character soup...

I see it differently. That's the name of the game. Language design is always striving toward making it more intelligible, but it is reasonable to expect pros to have command of the language.

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

#198

Post by vips7L »

jstanley wrote: post #128
Defletter wrote: post #102

Earlier quoted context omitted.

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

> What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch? I could forgive that. The TypeScript case is more like "what if instead of checking the types we just actually don't check the types?".

Compiler exhaustion is such a useful feature. I can’t believe TS doesn’t have it.

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

#199

Post by ibejoeb »

MrJohz wrote: post #139
another_twist wrote: post #121

Earlier quoted context omitted.

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…

Absolutely. It's contrived example. If you control the API, you'd be better to rewrite it:

   type Current = { amps: number; };
   type Ac = { kind: "ac" } & Current;
   type Dc = { kind: "dc" } & current;
   const currentToDc = (c: Current): Dc => ...
   const acToDc = (c: Ac): Dc => ...
And it would flow more naturally. Or define a CurrentKind and include it in current if you don't need to handle the scalar. There are plenty of better ways. That's also something that you can become accustomed to and recognize when you have a weak API.

I'm not really trying to make a case for `satifies`, but it can be handy and clean in some circumstances, especially when you're constrained by a third-party API.

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

#200

Post by RussianCow »

tshaddox wrote: post #186
jstanley wrote: post #128

Earlier quoted context omitted.

> What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch? I could forgive that. The TypeScript case is more like "what if instead of checking the types we just actually don't check the types?".

This is how all static type checking works. What programming language do you have in mind that does static type checking and then also does the same type checking at runtime? And what would you expect this programming language to do at runtime if it finds an unexpected type?

I think the point is that other languages make guarantees that ensure you don't have to do any runtime checking. In TypeScript, it's far too easy (and sometimes inevitable) to override the type checker, so some poor function further down into the codebase might get a string when it expects an object, even though there are no type errors.
Post reply on HN