The `satisfies` operator in TypeScript 4.9 is a game changer

[jrnxf]

perfect explanation. thanks for keeping it short!

[enverusta]

In my opinion, ts already does that if you put type before the initialization:

type Color = {
r: number,
g: number,
b: number
} | string;


const red: Color = 'red'
const blue: Color = {
r: 0,
g: 0,
b: 255
}

[EthanStandel]

EDIT: Steve responded both here and on Reddit so I just continued the conversation over there.

Also commented on Reddit, but I figured I'd throw it out here as well:

This still doesn't make sense to me... If you just say `const blue = "blue";` then that type is defined as `"blue"` which inherently extends `string` and inherently is a subtype of your `Color` type. So if you had a function that took in a `Color`, you can pass a `string` to it, you don't need to tell the compiler that this string satisfies something that it's already a subtype of.

So what's the difference between `const blue = "blue";` as opposed to `const blue = "blue" satisfies Color;`? In this example, the compilation behavior is exactly the same. The compiler maintains the knowledge that `blue` is a `string` and thus a subtype of `Color` which was inherent in it's assignment.

EDIT: I've been pacing and I think I get it, but I straight up think it's bad practice. The way I see it, it's a way of validating types at assignment time. So it doesn't change the compiler from if you just used the assignment type, but it will validate that the assignment type is a subtype of what you're looking for. But to me, this goes against what makes TypeScript good. It's a strict typing system for a dynamic language. So don't validate types on assignment or instantiation, validate them when you use them. If you have a thing you think is a color, just use it how you want until you pass it to a function that disagrees with you and tells you that "no that's not the type I want." Then you figure it out. This just adds verbosity where it's not needed.

Dude I love TypeScript but this syntax is just a bad addition. It just overcomplicates type validation.

[raianmr]

`satisfies` *almost* fixed the problem of type-checking plain old function definitions for me, but it seems to only check return types and falls flat on its face for parameter types. maybe its implementation is bugged for now idk

[kulbirsingh]

What extension do you use to get the values to display?

[dzilbxp]

I wouldn't say this is a game changer, but it's okay and nice to have.

[Mitsunee_]

I have never gotten `as const satisfies` to work for me. I keep finding myself wanting to use that with the Record utility type a lot.

[MarkNorgate]

Duplicate comment from Twitter…but what are the use cases for “satisfies”? When would you ever want one of a union of types checked in this way?

[TheMikkelet]

Can this be used to validate json? will `const response.body satisfies RequestData` throw an error I can respond to?

[Racle]

Why there is three different ways to do things?

Why isn't satisfies just default way?

Is there cases when you don't want that kind of completion and type checking?

This is coming from non TS programmer, so this behavior just seem stupid.

[altairbueno]

satisfies is stupid. The compiler should be able to do it automatically

[nomoredarts]

If you ever find it handy, know that there is problem with your code