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

161–170 of 217 posts

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

#161

Post by chuckadams »

pjerem wrote: post #122
wk_end wrote: post #24

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

I’d say it depends. I always advocate for code that is easy to read and to understand, but in extremely rare conditions, hard to read code is the better solution. Especially when it comes to signatures in Typescript, complex signatures can be used to create simple and ergonomic APIs. But anyway you shouldn’t be allowed to push anything like this without multiple lines of comments documenting the thing. Unreadable cod…

Comments and tests. Vitest supports unit tests for types.

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

#162

Post by Normal_gaussian »

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 is neither sound nor complete and was defined that way, beating out other competitors that were sound and/or complete.

What I mean to say is - TypeScript isn't proof.

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

#163

Post by shortrounddev2 »

swiftcoder wrote: post #153
wk_end wrote: post #24

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

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

#164

Post by Normal_gaussian »

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 }

This is what I do:

   class AbsurdError extends Error {
     constructor(public value: unknown, message: string) {
       super(message);
       this.name = 'AbsurdError';
     }
   }
   
   function absurd(value: never, message: string) {
     throw new AbsurdError(value, message);
   }
Including an error message and an error type helps if one does slip through to runtime. Additionally, the AbsurdError can be caught and escalated appropriately. And finally the absurd function can be used in an inline ternary etc. where alternatives like throw cannot.

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

#165

Post by Normal_gaussian »

mcintyre1994 wrote: post #144

Satisfies is very useful as a library author for testing your types. You can write `typetest` files that don't become part of the bundle but are compiled. One example is that we have a TS library for a JSON-RPC server that is horribly complex on the server side, returning different shapes of output based on input params. I don't think it can be typed with OpenAPI etc, but it can be with Typescript method overloads. B…

You can use multiple tsconfig files to remove the compile time issue; this is quite common for test files anyway. Its not unusual to see one for CI & IDE and one for compilation, the compilation one having a much more limited scope of files.

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

#166

Post by intellix »

thomasikzelf wrote: post #130
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.

If Typescript is javascript with types bolted on, Rescript is javascript with types the way it should have been. Sound types with low complexity. https://rescript-lang.org/

That syntax is so alien to me as a JS/TS developer. I mean coffeescript was as well until JS slowly introduced it all.

It would be cruel for me to force ReScript onto the team because they'd all need to reskill. I could only use it for a private project and then hire exclusively for it afterwards

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

#167

Post by sandblast »

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

Aren't these bugs that could be "simply" reported and fixed? Or maybe those would get a label "not a bug" attached by the TS creators for some reason?

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

#169

Post by rtz121 »

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

> For example, I don't ever see anyone using `dynamic` or `object` in C#

I have bad news for you

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

#170

Post by rtz121 »

samdoesnothing wrote: post #93
epolanski wrote: post #18

Earlier quoted context omitted.

I couldn't care less about mathematics, but I do care about making impossible state impossible and types documenting the domain. If you type some state as: isLoading: boolean result: Foo hasError: boolean errorMessage: string | null then you're creating a giant mess of a soup where the state of your program could have a result, be loading and an error at the same time. If you could recognise that the state of your pr…

You can encode that "correctly" in pure JS class LoadingState extends State {} class ResultState extends State {} class ErrorState extends State {} const state: State = new LoadingState Generally it's a bad pattern to have dependant fields like your example, but you don't need TS to solve it.

Thats OOP, we don't do that anymore!!! /s
Post reply on HN