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 }
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.
So a couple use cases that I think may help to point out: One would be if you want to change the Color type later, e.g. to only support specific strings, like `Color = 'blue' | 'red' | ... | { ...}`. In this case if blue had a typo, like `const blue = 'bleu'`, your IDE would catch it. It would also autocomplete the valid values as expected. And the type error would be concentrated on the definition, rather than every usage of it, making it more clear where the source of the problem is Another, maybe better example, is if you use the object format. Besides the IDE autocompleting the keys and TS checking if your keys are correct, reactors are much easier too. So if you want to change the keys from r/g/b to red/green/blue, you can do that project wide in one command assuming you use `satisfies`, but it would not be able to help you here without
`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
There is a great one in this video at 7:20 for Next.js ua-cam.com/video/Danki1DyiuI/v-deo.html and here are some great examples for Prisma www.prisma.io/blog/satisfies-operator-ur8ys8ccq7zb
This is not really an answer to the use case question, but *"satisfies"* looks like a very nice semantic improvement to help other developers (or yourself next week) better understand the intent of the *"const".*
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.
"as" is used for basically telling typescript to just assume you're correct, rather than going through the trouble of correctly typing the value in a way that typescript can validate the type. This used to be a lot more useful back when typescript was far dumber than it is now. I agree that "satisfies" should be the default going forward.
i think its pretty clear if you've watched the video carefully that all these do different things. as to why typescript suffers from analysis paralysis all too often, its because it's a hosted language that's always guessing what the programmer wants. this is in contrast with languages that come with type hinting natively e.g., python where things don't feel this fragmented
@@Aedaeum Except it doesn't work in all cases. Sometimes it won't let you cast because the object you're casting and what you're casting into are very distinct.
Read about some killer use cases for `satisfies` in my full article: www.builder.io/blog/satisfies-operator
perfect explanation. thanks for keeping it short!
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
}
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.
So a couple use cases that I think may help to point out:
One would be if you want to change the Color type later, e.g. to only support specific strings, like `Color = 'blue' | 'red' | ... | { ...}`. In this case if blue had a typo, like `const blue = 'bleu'`, your IDE would catch it. It would also autocomplete the valid values as expected. And the type error would be concentrated on the definition, rather than every usage of it, making it more clear where the source of the problem is
Another, maybe better example, is if you use the object format. Besides the IDE autocompleting the keys and TS checking if your keys are correct, reactors are much easier too. So if you want to change the keys from r/g/b to red/green/blue, you can do that project wide in one command assuming you use `satisfies`, but it would not be able to help you here without
`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
I wouldn't say this is a game changer, but it's okay and nice to have.
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.
What extension do you use to get the values to display?
👍
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?
There is a great one in this video at 7:20 for Next.js ua-cam.com/video/Danki1DyiuI/v-deo.html and here are some great examples for Prisma www.prisma.io/blog/satisfies-operator-ur8ys8ccq7zb
This is not really an answer to the use case question, but *"satisfies"* looks like a very nice semantic improvement to help other developers (or yourself next week) better understand the intent of the *"const".*
👀
Can this be used to validate json? will `const response.body satisfies RequestData` throw an error I can respond to?
Sadly no, this is purely a compile time check (rather than a runtime check)
We're using zod for this exact purpose. You can also generate a type from its schema for use with TypeScript.
Interface or types
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.
"as" is used for basically telling typescript to just assume you're correct, rather than going through the trouble of correctly typing the value in a way that typescript can validate the type. This used to be a lot more useful back when typescript was far dumber than it is now. I agree that "satisfies" should be the default going forward.
i think its pretty clear if you've watched the video carefully that all these do different things. as to why typescript suffers from analysis paralysis all too often, its because it's a hosted language that's always guessing what the programmer wants. this is in contrast with languages that come with type hinting natively e.g., python where things don't feel this fragmented
@@Aedaeum Except it doesn't work in all cases. Sometimes it won't let you cast because the object you're casting and what you're casting into are very distinct.
@@parlor3115 There's always edge cases; that's a given.
satisfies is stupid. The compiler should be able to do it automatically
typescript moment
If you ever find it handy, know that there is problem with your code
Avoid JavaScript/Typescript