@@alexismandelias to the uninitiated, both are confusing. I totally get that. The reason I find `T extends T` to be better is because triggering union distribution is the only use for that. Whereas sometimes you see people use `T extends any` in generic parameters (perhaps to get around JSX rule issues, but perhaps just while thinking through an issue before they put something better there (there's a typescript-eslint rule `no-unnecessary-type-constraint` for this)). Also the "similar but not the same" `T extends any[]` syntax is very commonly used for other purposes, but at a glance looks similar. With that context in mind, `T extends T` _only_ being used for this one thing is at least a little tiny bit easier because it's only got this purpose and this purpose alone. Does that make sense? I've been thinking of making a video on the Michigan TypeScript channel to discuss this literal topic of one versus the other (just for fun), so I'd love to hear your feedback.
I would personally prefer `T extends any`, because I know exactly what it does, at a glance. I know for certain, from all my TypeScript experience, that `any` covers all types. For the `T extends T` syntax, I would have to know if *every* single type extends itself. Which I don't. I mean, it seems straight forward, but doing `x === x` seems straight forward too, and that does *not* return true for every value (it's false for `x = NaN`). So I kept thinking if there was a type that somehow didn't extend itself, for some weird reason. Maybe `null`? Or maybe `never`? If I stumbled across `T extends T` in some codebase, I would 100% have to google what it does, but `T extends any` is obvious. And if you really hate `any` that much, you can always write `T extends unknown`.
On top of this, if you want to simplify the type, so instead of seeing "Omit | Omit", is to reconstruct the type which can be done generically like this: type Simplify = { [P in keyof T]: T[P] } & {}; The "& {}" at the end is key here. You could also replace it with a "[][0]" if you wanted. The idea is just to tell TypeScript to create a new type from it rather than trying to be smart about it.
Great content I really like where this channel is going. One thing I would have liked would have been one more application example or use case. Also when there were all the different but similar types listed, a comment above each showing their type signature for an easier overview.
Haven't thought about using extends, what I found works is using a mapped type to iterate a union type A = { [ member in Union]: Array } type B = typeof A[number] I find it a bit more verbose.
I really like what TS is bringing to the web, and what the community is building and teaching with it... but this is so hackish 😑 makes me wonder why there's no built-in support for this. (Awesome video nonetheless, it was cool to learn this)
Why this is allowed: export interface IUserAccessMFAActivation { access_token: string; mfa_activation: boolean; } export interface IUserMFARequired { mfa_required: boolean; mfa_nonce: string; } type IUserShopAuthResponse = IUserAccessMFAActivation | IUserMFARequired; function test(): IUserShopAuthResponse { return { mfa_nonce: 'aa', mfa_required: true, access_token: 'aa', mfa_activation: true, }; } The function should complain about the return, I want to be allowed only to return: { access_token: string; mfa_activation: boolean; } or { mfa_required: boolean; mfa_nonce: string; } can i fix it with distributive conditional types?
Oh nice! Just hit this issue last Friday, wasn’t sure what’s going on. Makes a lot of sense now. Thanks, you just saved me a ton of boilerplate! Awesome channel by the way, this is the kind of in depth content we miss :)
Dude, this is awesome. Glad I found your channel. Please continue with advanced/niche(ish) typescript features. I feel like very few people actually have access to this kind of information through typescript docs and forumns.
It's great when UA-cam/content creators do this; I discovered this would be perfect for my project late last night. Then I woke up this morning, and this was one of the first things in my recommended feed. Super cool! Sometimes the 'idea stars' line up, it seems like 😆
I was very fortuante to find your channel a few days ago. I'm trying to teach myself Angular and apparently NG and TS are like best friends or something. The way you present the material is just spot on. Comming from C# background this stuff just blows my mind, I used to always make fun of JS for its quirkiness but I have to say TS type system is pretty incredible. Thank you for doing an awesome job with these vids!
I wish I found this channel sooner, about 3 weeks ago I ran into this exact issue. StackOverflow helped by providing something akin to your DistributedOmit, but it would have been nice to just know how this works.
I didn't knew that `boolean` is treated as a union of true and false! that was new for me! type UnwrapUnion = T extends T ? Array : never type BooleanArr = UnwrapUnion ^ true[] | false[]
I'm glad to see you like the `T extends T` syntax rather than the `T extends any` variant. I 100% agree!
How is more clear than ???
@@alexismandelias to the uninitiated, both are confusing. I totally get that. The reason I find `T extends T` to be better is because triggering union distribution is the only use for that. Whereas sometimes you see people use `T extends any` in generic parameters (perhaps to get around JSX rule issues, but perhaps just while thinking through an issue before they put something better there (there's a typescript-eslint rule `no-unnecessary-type-constraint` for this)). Also the "similar but not the same" `T extends any[]` syntax is very commonly used for other purposes, but at a glance looks similar.
With that context in mind, `T extends T` _only_ being used for this one thing is at least a little tiny bit easier because it's only got this purpose and this purpose alone.
Does that make sense? I've been thinking of making a video on the Michigan TypeScript channel to discuss this literal topic of one versus the other (just for fun), so I'd love to hear your feedback.
I would personally prefer `T extends any`, because I know exactly what it does, at a glance. I know for certain, from all my TypeScript experience, that `any` covers all types. For the `T extends T` syntax, I would have to know if *every* single type extends itself. Which I don't. I mean, it seems straight forward, but doing `x === x` seems straight forward too, and that does *not* return true for every value (it's false for `x = NaN`). So I kept thinking if there was a type that somehow didn't extend itself, for some weird reason. Maybe `null`? Or maybe `never`?
If I stumbled across `T extends T` in some codebase, I would 100% have to google what it does, but `T extends any` is obvious. And if you really hate `any` that much, you can always write `T extends unknown`.
T extends T makes perfect sense if you think of it as the identity of T.
5:51 You can write `K extends PropertyKey` instead of typing out `string | number | symbol` individually.
Very cool, TIL!
or `K extends keyof T`
@@nightfury1250 That would prevent you from Omitting keys that don't exist in the Type, which is useful in many cases.
It has the added benefit of making it very clear what the intend is.
@@nefthy yes exactly what I was thinking of
On top of this, if you want to simplify the type, so instead of seeing "Omit | Omit", is to reconstruct the type which can be done generically like this:
type Simplify = { [P in keyof T]: T[P] } & {};
The "& {}" at the end is key here. You could also replace it with a "[][0]" if you wanted. The idea is just to tell TypeScript to create a new type from it rather than trying to be smart about it.
Great content I really like where this channel is going. One thing I would have liked would have been one more application example or use case. Also when there were all the different but similar types listed, a comment above each showing their type signature for an easier overview.
Great feedback, appreciate it! Thanks for watching!
Haven't thought about using extends, what I found works is using a mapped type to iterate a union
type A = { [ member in Union]: Array }
type B = typeof A[number]
I find it a bit more verbose.
I really like what TS is bringing to the web, and what the community is building and teaching with it... but this is so hackish 😑 makes me wonder why there's no built-in support for this.
(Awesome video nonetheless, it was cool to learn this)
I already know typescript sucks,
you don't have to sell it to me.
Wow! Finally something useful that I didn't know about typescript. Great video, great explanation.
Why this is allowed:
export interface IUserAccessMFAActivation {
access_token: string;
mfa_activation: boolean;
}
export interface IUserMFARequired {
mfa_required: boolean;
mfa_nonce: string;
}
type IUserShopAuthResponse = IUserAccessMFAActivation | IUserMFARequired;
function test(): IUserShopAuthResponse {
return {
mfa_nonce: 'aa',
mfa_required: true,
access_token: 'aa',
mfa_activation: true,
};
}
The function should complain about the return, I want to be allowed only to return:
{
access_token: string;
mfa_activation: boolean;
}
or
{
mfa_required: boolean;
mfa_nonce: string;
}
can i fix it with distributive conditional types?
Great video Andrew.
Really good video, thank you. I like your content - concise and helptful.
Also, 10K subscribers ftw!!!
Man its so hard to come across such content in youtube given there is so much repetition. Thanks for doing that!
OMG! I think I've faced similar issue too many a time in my work, I'll have to check tomorrow.. Thanks a million!!
i failed to understand fully but i helped a lot to make a my typescript working. thanks
Oh nice! Just hit this issue last Friday, wasn’t sure what’s going on.
Makes a lot of sense now. Thanks, you just saved me a ton of boilerplate!
Awesome channel by the way, this is the kind of in depth content we miss :)
great as always
sometimes I think typescript makes us look like crazy people. ⚡️T extends T ⚡️
It is crazy. I miss some syntactic sugar for stuff like that.
Happy for you bro
Dude, this is awesome. Glad I found your channel. Please continue with advanced/niche(ish) typescript features. I feel like very few people actually have access to this kind of information through typescript docs and forumns.
It's great when UA-cam/content creators do this; I discovered this would be perfect for my project late last night. Then I woke up this morning, and this was one of the first things in my recommended feed. Super cool! Sometimes the 'idea stars' line up, it seems like 😆
I was very fortuante to find your channel a few days ago. I'm trying to teach myself Angular and apparently NG and TS are like best friends or something. The way you present the material is just spot on.
Comming from C# background this stuff just blows my mind, I used to always make fun of JS for its quirkiness but I have to say TS type system is pretty incredible. Thank you for doing an awesome job with these vids!
Seen unions so many times I'm starting to pronounce it like onions in my head
😂😂🧅🧅
What is this declare keyword he used
This channel always produces quality content
Learned something new - thanks 💪💪
this was nice, thanks for the vid!
I wish I found this channel sooner, about 3 weeks ago I ran into this exact issue. StackOverflow helped by providing something akin to your DistributedOmit, but it would have been nice to just know how this works.
I didn't knew that `boolean` is treated as a union of true and false! that was new for me!
type UnwrapUnion = T extends T ? Array : never
type BooleanArr = UnwrapUnion
^ true[] | false[]
huh, very cool, that's not what I would have expected. Thanks for sharing!
ninja 🥷