Man, being able to find this channel while learning TypeScript is a true blessing. I'll will alway looking for this channel when having problems with Typescript. Thank you Matt
The stuff about apis is golden, I recently did a similar thing to stop typing JSON responses as 'any' and it really helped with leveraging Typescript to handle edge cases etc. I haven't used schema validation yet, but seeing how clean the code is, it's really enticing.
This is actually really awesome. The light bulb moment for me was "Take generic from inward to outward": as in, generics can be inferred from the arguments passed to a function. This is very poweful
10:07 To get the proper return type of your function, instead of type assertion, you can add it as return type to the function: const typeObjectKeys = (obj:TObj):Array =>{ return Object.keys(obj) } This would result in the perfectly valid error of "Type 'string' is not assignable to type 'never'", since empty arrays can be passed to it. Since keyof keeps the original type but Object.keys returns strings, this can cause runtime errors. The proper implementation would assure that only objects with valid keys can be accepted by the function: const typeObjectKeys = (obj:TObj):Array =>{ return Object.keys(obj) }
Hey Matt, your videos are very helpful, you're covering features in TypeScript I needed and didn't know exist. It'd be so great if you could give and example of a scenario before explaining a TS solution, for the more complicated ones. Leaving out inline object types (like { firstName: string, lastName: string } would be nice too just so there's less to process heh.
Thanks for sharing, great tips and I didn't know much about generic types. I just fear huge overheads, especially in the code readability department. When these types of codebases are written in real world scenarios, things turn pretty ugly pretty quickly. And usually, when the wizard who wrote this dark spells on a magic mushroom microdose induced flow state goes for the better paying company, the rest of people is left scrambling in chaos. Sometimes, especially for large companies with mixed teams, it's ok to be a bit verbose and repetitive if it leads to faster handovers and a better overall team experience. That said, we (as the JS community) need to mature towards more advanced design patterns. Was great learning about generic types today, thanks for sharing!
In general, you'll mostly see generics, conditional types, the "infer" keyword, etc used in packages to make them as strictly typed but broadly usable as possible. In real-world production code, I would indeed avoid complex types and be more verbose about your typing.
Amazing video! Thank you! One question tho, for tip 7 (10:07) wouldn't casting as Array potentially give wrong types (and thus potentially wrong linting) if some of the keys of the object are not defined as strings? Since Object.keys returns strings and even if the key is not a string (e.g. number) it's converted to a string, but `keyof TObj` doesn't convert to string and keeps the original type. In the example, that problem doesn't come up since both the "name" and "age" keys are strings, but for e.g. { name: "John", 42: "whatever value" }, if you later try to do some string-specific operation on `result`, like `result[1].charAt(0)`, the IDE will flag it as something like `Property 'charAt' doesn't exist on type '"name" | 42'`, when that's a perfectly valid thing to do since Object.keys will return the string "42" for the number key 42
13:42 From a C# background `TKey extends keyof TObj` makes no sense for me. Why does this describe the `typeof TValue`? I hope I can internalize the solution because I stumble over this problem from time to time and asking myself again and again how the syntax was supposed to be. ^^
@Matt, do you know why in example N8 (getValue function) we need explicitly provide the second generic for the keys - 'TKey extends keyof TObj'? Why the setting of the arg 'key: keyof TObj' is not enough?
I'll attempt to answer in the absence of Matt. The issue is how to get TS to connect the return type with the input type. Since the input type is an object with multiple attributes, each with a different type, we don't want the return type to be a union of all those possible types, we want it to be keyed to the 'key' input arg. Hence we use the 2nd generic and infer the return type. On a deeper level, I'm uncertain "why" this is necessary, why TS didn't have enough information to start with. Which is something for Matt to explain.
Coincidentally, I just watched your generics video on LWJ and was doing those exercises. This is a great video. Lot of things clicked for me with generics! Thanks Matt!
Thank you Matt for all this great content! May be consider slowing down a bit so we get time to grasp the content and avoid head spinning injury by having to rerun videos/ play at lower speed with robot voice 😀
everytime I try to use keyof in generics I end up with it staying at the union type. Yesterday I was trying to merge all my getBundledFooBar functions into a single util and it just never wanted to work for me. Really confused as to what specifically makes typescript understand when a keyof-based parameter is not the union of all keys.
That was great but you did one mistake in tip 7 you don't need to use "as" in that example if you restrict the type of the object to have keys of type string. Object.keys doesn't return symbols in JavaScript but the keyof does. const typeObjectKeys = ( obj: TObj ): Array => { return Object.keys(obj); };
This was a brilliant video. You are clearly incredibly knowledgeable in all things typescript so instead of just giving praise I'd offer a tiny bit of criticism, maybe it's worth something too you, maybe not. Ive watched all your videos, some multiple times, and the one thing I notice is that some examples are a little too contrived, or at least it's not clear where I'd ever use a certain tip. Ive been a professional ts dev for about a year, and I'm no where near as good as you are but I really struggle to see the use cases in some of the tips, I'm not saying they don't exist, it's just I can't see them. Your zod example is a perfect example of the type of tips I find most useful, it's clear the real world use case and the example you use is a something we might actually see in our own code bases. Basically I'm saying is love some more real world examples for some of the more complex tips you give. I think part of it is your older videos were quite short which are great for a quick look and you do a great job of explaining how it works clearly, but then the video just ends and I'm left wondering how to apply it somewhere. Overall 9/10, just thought this might be more useful just another clap emoji. Thanks for your videos, looking forward to the next one as always.
That's interesting! I've heard this criticism before but I consider this video to be a good example of me using real-world examples. Type safe object keys, typing Set, making type-safe fetches, integrating with Zod are all things I've been asked how to do. Which example in particular felt too abstract for you?
This video is exactly what I needed! P.S. it’s still really hard for me to get over the fact that non-Chinese people don’t know how to count to 10 on one hand.
So nice video!! I’m starting with typescript so not sure if I get it well but what I understand is that generics help typescript to infer on the arguments we pass in a function and give the proper return type. So a well defined generic in a function will give a much easier function handling when using it. Sorry if it’s not clear for me just try to understand. Thanks anyway for this video will work on it.
Outstanding. Last time I used generics was C++ and Java in the late 90s probably before most of the other commenters were born😂 and it’s really great to see the inference capabilities to avoid “type stuttering” you otherwise get.
Hey Matt, another great video! In the end of the video you still have to create a zod object of the type specified. Can you make zod infer the object from the schema and implement it?
Really great content! Please provide a Nextjs 14 course. I follow stephen grider, but your way of teaching impressed me. I would like to work for free for you! I want to improve my coding!
hmm... Sorry for my ignorance but re. tip 6 what is the point of and then "let highestKey: keyof TObj" when we can do "function(obj: Record) and then (obviously) "let highestKey: string" - that also takes advantage of Tip 4? Why should we do it the painful way?
Because then the highest key would be too loose as a type, and you wouldn't be able to index into the original object with it. Having keyof there means a nicer API for those consuming the function.
@@mattpocockuk I think I can understand the philosophy, but am I wrong to think that with the Record the "keyof" will have no way to be anything but string anyway? In other words should we sacrifice our knowledge that a particular type 'has to' be - say - string, for the sake of writing a more sophisticated looking code? Thank you for taking the time to reply mate!
what is this addon with ?^ that shows the typing of the consts as they change according to the different types that are fed to the generic type? for example that ^? const result: ...." with the changing types. anybody?
I have the task to write a blog post about generics and you, my lord, have completely saved me in the most important thing to do it, understanding them!
One thing I don't understand - why does TS use inference here: `(obj: TObj, key: TKey)` But not here: `(obj: TObj, key: keyof TObj)` Aren't we essentially providing TS with the same information?
i wish i'd seen this video like four months ago, when i refactored an entire routing architecture, for which i found myself using what here you will see as tips 1 through 9. Had to learn it the harder way. this video would have really made the learning curve less steep. I
Nice content, we are using it a lot with react applications. I will ask why in part of generic we need to write like instead a simple . Thanks for sharing your knowledge:)
Hi, is there any difference between 'object extends T' and 'T extends object'? If so, what could be an example to best illustrate a use case for one vs the other?
Example 4 I think is not a really good idea, especially if you are working on a team or a big project, might work well for small stuff. The reason is simple, you wouldn't really write addIdToObject( ... ). You would normally have that out in a type or an interface, so it would be more like addIdToObject({ ... }), and now if you are using IdType anywhere else in the code, if you change it, you will get all of the errors that you need. However if you have left the type as inferred, you could simply say pass in an extra argument to the function, or remove an argument, and you would never know that you just broke 50 different things until it gets to production and you get angry clients :)
Thanks for the videos Matt. I can imagine they take a lot to put together. Just something I've noticed, you speak really fast and take almost no breaths between words 😅 then you go from one topic to the next with almost no breaks in-between. For me personally It's really tough to follow because these are kind of complicated topics you are covering. Again, I really appreciate the time and effort you put into your videos. Just a bit of constructive feedback from one viewer. 👌🏾
in example 2, wouldnt it make more sense to just "hard"-type the return type of promise? It makes the function and the function call much more readable
Ish - by making it generic you leave open the possibility of TS being able to infer cool stuff from it. It's a bit of a contrived example, albeit one that is based in code that I've seen in the wild (in cal.com's repo, for instance). It's really a way of setting up exercise 4 and 10.
@@mattpocockuk i think what threw me off a bit is that these two functions are directly below eachother. Thinking about it more, make fetch is probably some sdk you import to get data (so something the libary auther writes), and you use the generic function argument to type your output. looking at it like this it makes sense ofc to do it your way - and you are right, there are examples all over (for example the pockerbase javscript sdk). thanks for the reply.
Sometimes `as` is unavoidable indeed, but your example is dangerous. You can easily use it in typed function like `type TA = { a: number }; function getAProps(a: TA) { return typedObjectKeys(a); }` and its result will be typed as `"a"[]` but you could put a value of some type that extends TA as an argument, like `const b = { a: 2, b: 3 }; getAProps(b);` and get `["a", "b"]` result wrongly typed as `"a"[]`.
Man, being able to find this channel while learning TypeScript is a true blessing.
I'll will alway looking for this channel when having problems with Typescript. Thank you Matt
Matt, you are the Wizard. I can't describe how helpful this video was for me. It's purely golden. Thank you for your work!
Please never stop doing these videos, you're my inspiration
The stuff about apis is golden, I recently did a similar thing to stop typing JSON responses as 'any' and it really helped with leveraging Typescript to handle edge cases etc. I haven't used schema validation yet, but seeing how clean the code is, it's really enticing.
This is actually really awesome. The light bulb moment for me was "Take generic from inward to outward": as in, generics can be inferred from the arguments passed to a function. This is very poweful
One of the best videos out there on Typescript Generics!
that's it im sold. Subbing to this gold channel
10:07 To get the proper return type of your function, instead of type assertion, you can add it as return type to the function:
const typeObjectKeys = (obj:TObj):Array =>{
return Object.keys(obj)
}
This would result in the perfectly valid error of "Type 'string' is not assignable to type 'never'", since empty arrays can be passed to it. Since keyof keeps the original type but Object.keys returns strings, this can cause runtime errors.
The proper implementation would assure that only objects with valid keys can be accepted by the function:
const typeObjectKeys = (obj:TObj):Array =>{
return Object.keys(obj)
}
Came here to say this ^ "as" is almost never the answer
I love you Matt, free contents that you produced are chef kisses. I am always craving for more.
Hey Matt, your videos are very helpful, you're covering features in TypeScript I needed and didn't know exist.
It'd be so great if you could give and example of a scenario before explaining a TS solution, for the more complicated ones.
Leaving out inline object types (like { firstName: string, lastName: string } would be nice too just so there's less to process heh.
Which extension is it which is giving type hints using "^?"
Yup I would love to know this also
twoslash-queries vscode extension.
@@nextmaker Thank you for this link :D
Hah nice, Matt just posted a video about this extension!
Chdck his most recdnt video
Thanks for sharing, great tips and I didn't know much about generic types.
I just fear huge overheads, especially in the code readability department. When these types of codebases are written in real world scenarios, things turn pretty ugly pretty quickly.
And usually, when the wizard who wrote this dark spells on a magic mushroom microdose induced flow state goes for the better paying company, the rest of people is left scrambling in chaos.
Sometimes, especially for large companies with mixed teams, it's ok to be a bit verbose and repetitive if it leads to faster handovers and a better overall team experience.
That said, we (as the JS community) need to mature towards more advanced design patterns.
Was great learning about generic types today, thanks for sharing!
In general, you'll mostly see generics, conditional types, the "infer" keyword, etc used in packages to make them as strictly typed but broadly usable as possible. In real-world production code, I would indeed avoid complex types and be more verbose about your typing.
The most helpful video I have seen for a while. :)
Adding to bookmark for using as a documentation.
Amazing video! Thank you!
One question tho, for tip 7 (10:07) wouldn't casting as Array potentially give wrong types (and thus potentially wrong linting) if some of the keys of the object are not defined as strings? Since Object.keys returns strings and even if the key is not a string (e.g. number) it's converted to a string, but `keyof TObj` doesn't convert to string and keeps the original type. In the example, that problem doesn't come up since both the "name" and "age" keys are strings, but for e.g. { name: "John", 42: "whatever value" }, if you later try to do some string-specific operation on `result`, like `result[1].charAt(0)`, the IDE will flag it as something like `Property 'charAt' doesn't exist on type '"name" | 42'`, when that's a perfectly valid thing to do since Object.keys will return the string "42" for the number key 42
You're right.
best video i have seen in a while on yt. thankyou!
13:42 From a C# background `TKey extends keyof TObj` makes no sense for me. Why does this describe the `typeof TValue`?
I hope I can internalize the solution because I stumble over this problem from time to time and asking myself again and again how the syntax was supposed to be. ^^
Brilliant video, learnt a lot - I've never really looked into generics before, so, now my Typescript knowledge really has gone up a level.
@Matt, do you know why in example N8 (getValue function) we need explicitly provide the second generic for the keys - 'TKey extends keyof TObj'? Why the setting of the arg 'key: keyof TObj' is not enough?
I'll attempt to answer in the absence of Matt. The issue is how to get TS to connect the return type with the input type. Since the input type is an object with multiple attributes, each with a different type, we don't want the return type to be a union of all those possible types, we want it to be keyed to the 'key' input arg. Hence we use the 2nd generic and infer the return type. On a deeper level, I'm uncertain "why" this is necessary, why TS didn't have enough information to start with. Which is something for Matt to explain.
@@jasonstewart7983 Thank you
Hey Matt,
I've been following you on X for sometimes and learned a lot from about TS.
And here as well.... Subscribed 😍
Coincidentally, I just watched your generics video on LWJ and was doing those exercises. This is a great video. Lot of things clicked for me with generics! Thanks Matt!
What's LWJ, if I may ask?
@@andyl.5998 Learn With Jason www.youtube.com/@learnwithjason
@@andyl.5998 Learn With Jason, if you haven't found it already
The more I watch your videos I love TS more! 🧡
Thank you Matt for all this great content! May be consider slowing down a bit so we get time to grasp the content and avoid head spinning injury by having to rerun videos/ play at lower speed with robot voice 😀
In example number 6, why do TObj extends Record when a mere Record would've sufficed?
Because you wouldn't get autocomplete on the key that comes back in the return type
Man, you are the sunshine!
Straight to bookmarks.
You're an amazing teacher!!
That number 8 tip was, in fact, really good, I didn't understand it before
everytime I try to use keyof in generics I end up with it staying at the union type. Yesterday I was trying to merge all my getBundledFooBar functions into a single util and it just never wanted to work for me. Really confused as to what specifically makes typescript understand when a keyof-based parameter is not the union of all keys.
I'm in love with that makeZodSafeFetch function! Thank you for this great video!
14:03 is the better part of this video 😁
How to make type argument required? That createSet() should throw a type error about missed type argument?
This man is on another level! Subbed!
Thanks, Great video! Look forward to going through it in total typescript
bro this is wonderful you explained it VERY well
this is absolute masterclass...
That was great but you did one mistake in tip 7 you don't need to use "as" in that example if you restrict the type of the object to have keys of type string. Object.keys doesn't return symbols in JavaScript but the keyof does.
const typeObjectKeys = (
obj: TObj
): Array => {
return Object.keys(obj);
};
This was a brilliant video. You are clearly incredibly knowledgeable in all things typescript so instead of just giving praise I'd offer a tiny bit of criticism, maybe it's worth something too you, maybe not.
Ive watched all your videos, some multiple times, and the one thing I notice is that some examples are a little too contrived, or at least it's not clear where I'd ever use a certain tip. Ive been a professional ts dev for about a year, and I'm no where near as good as you are but I really struggle to see the use cases in some of the tips, I'm not saying they don't exist, it's just I can't see them. Your zod example is a perfect example of the type of tips I find most useful, it's clear the real world use case and the example you use is a something we might actually see in our own code bases. Basically I'm saying is love some more real world examples for some of the more complex tips you give. I think part of it is your older videos were quite short which are great for a quick look and you do a great job of explaining how it works clearly, but then the video just ends and I'm left wondering how to apply it somewhere.
Overall 9/10, just thought this might be more useful just another clap emoji. Thanks for your videos, looking forward to the next one as always.
That's interesting! I've heard this criticism before but I consider this video to be a good example of me using real-world examples. Type safe object keys, typing Set, making type-safe fetches, integrating with Zod are all things I've been asked how to do. Which example in particular felt too abstract for you?
good feedback ≠ criticism
This video is exactly what I needed!
P.S. it’s still really hard for me to get over the fact that non-Chinese people don’t know how to count to 10 on one hand.
Tip 10 is the best one! Just did something similar the other day.
So nice video!! I’m starting with typescript so not sure if I get it well but what I understand is that generics help typescript to infer on the arguments we pass in a function and give the proper return type. So a well defined generic in a function will give a much easier function handling when using it. Sorry if it’s not clear for me just try to understand. Thanks anyway for this video will work on it.
Great video. Not many new things for me. But it's really good to see someone making truly advanced topic videos on TS.
Keep it up 🚀
Question: What is the // ^2 in your code, and why it log the variable all the time ?
Is it a plugin or typescript external ?
Its a VSCode extension. He covered it in this video before:
ua-cam.com/video/u0adKDu--cA/v-deo.html
Nice work Matt
Amazing video Matt, thank you so much!
Thanks very much for the video. This is a real eye opener.
I usually don't make comments, but this was a great video. Thank you !
7:43 Any difference between doing that and doing extends Function?
Outstanding. Last time I used generics was C++ and Java in the late 90s probably before most of the other commenters were born😂 and it’s really great to see the inference capabilities to avoid “type stuttering” you otherwise get.
This video makes me love more typescript!
I just love final part imo
Hey Matt, another great video! In the end of the video you still have to create a zod object of the type specified. Can you make zod infer the object from the schema and implement it?
I pressed the like button, I got a surge of dopamine 👍. Really interesting video, generics are fun!
this video is just immensely helpful
Really great content! Please provide a Nextjs 14 course. I follow stephen grider, but your way of teaching impressed me.
I would like to work for free for you! I want to improve my coding!
Great video, Matt. Hats off ;)
very clear explanation, amazing
This video singlehandedly dissolved my fear of "complicated" typescript. I'm pretty new to it, but now I want to use generics everywhere
hmm...
Sorry for my ignorance but re. tip 6 what is the point of and then "let highestKey: keyof TObj" when we can do "function(obj: Record) and then (obviously) "let highestKey: string" - that also takes advantage of Tip 4? Why should we do it the painful way?
Because then the highest key would be too loose as a type, and you wouldn't be able to index into the original object with it. Having keyof there means a nicer API for those consuming the function.
@@mattpocockuk I think I can understand the philosophy, but am I wrong to think that with the Record the "keyof" will have no way to be anything but string anyway?
In other words should we sacrifice our knowledge that a particular type 'has to' be - say - string, for the sake of writing a more sophisticated looking code?
Thank you for taking the time to reply mate!
@@rkingham3181 The point here is that keyof T is _more_ specific than string. I.e. it's a specific set of literals.
@@mattpocockuk ah...
I think I got it now!
I don't know what it is about generics, but they just make my brain shut off. Looking forward to remedying this with this video.
Many cool pieces of advice. Thank you!
Nice video! Another tip is you can do generic type inference from a function return type, in the same way you can do it for function parameters
This is awesome Matt 🙌🏻
13:34 nice! this is useful stuff
what is this addon with ?^ that shows the typing of the consts as they change according to the different types that are fed to the generic type?
for example that ^? const result: ...." with the changing types.
anybody?
I have the task to write a blog post about generics and you, my lord, have completely saved me in the most important thing to do it, understanding them!
One thing I don't understand - why does TS use inference here:
`(obj: TObj, key: TKey)`
But not here:
`(obj: TObj, key: keyof TObj)`
Aren't we essentially providing TS with the same information?
I have the same question. I can't understand why it has this difference
probably the return type becomes a union because it split the inner keys in the object itself.
At 14:00 I laughed so hard. Really good explanation of generics. Good job.
Yeah right, the guy really likes Generics LOL!
What a wonderful video! I wish I can like it more than once. Thanks a lot Matt
amazing stuff Matt thanks for those tips🙌 they were really 🔥🔥🔥
i wish i'd seen this video like four months ago, when i refactored an entire routing architecture, for which i found myself using what here you will see as tips 1 through 9.
Had to learn it the harder way. this video would have really made the learning curve less steep.
I
Love this Matt, thank you so much
Hi Matt, great content as always, may I ask what extensions or settings you have that allows inlay hints to popup where there is "// ^?"
Twoslash Query Comments
Default params in TS o.O Whaaaaaaaaaaaaaat ? Matt, tip after tip and I think you can't amaze me more and there you go :D Matt, you're our hero 🍻
Amazing Matt ... Just Amazing !!! Thanks
Thank you Matt!
Can you do one with axios? I literally get confused using axios with typescript and make my responses and errors typesafe
Really good explanation! 👍
Nice content, we are using it a lot with react applications. I will ask why in part of generic we need to write like instead a simple . Thanks for sharing your knowledge:)
Because in .tsx files is parsed as a JSX node, but isn't.
Hi, is there any difference between 'object extends T' and 'T extends object'? If so, what could be an example to best illustrate a use case for one vs the other?
Thanks man, very good content.
Excellent tips, thank you!
Default type parameter is actually genious feature
Like and subscribed. Awesome tips, they proved to be particularly useful for me just to learn.
Example 4 I think is not a really good idea, especially if you are working on a team or a big project, might work well for small stuff. The reason is simple, you wouldn't really write addIdToObject( ... ). You would normally have that out in a type or an interface, so it would be more like addIdToObject({ ... }), and now if you are using IdType anywhere else in the code, if you change it, you will get all of the errors that you need. However if you have left the type as inferred, you could simply say pass in an extra argument to the function, or remove an argument, and you would never know that you just broke 50 different things until it gets to production and you get angry clients :)
Thanks for the videos Matt. I can imagine they take a lot to put together. Just something I've noticed, you speak really fast and take almost no breaths between words 😅 then you go from one topic to the next with almost no breaks in-between. For me personally It's really tough to follow because these are kind of complicated topics you are covering. Again, I really appreciate the time and effort you put into your videos. Just a bit of constructive feedback from one viewer. 👌🏾
great, direct into the point
Great video!
Did you invent Typescript? Lol. Just kidding. I watch your videos all the time. Very enjoyable.
I love this video so much !
Thank you for the effort to make this awesome and useful video, Much love
in example 2, wouldnt it make more sense to just "hard"-type the return type of promise? It makes the function and the function call much more readable
Ish - by making it generic you leave open the possibility of TS being able to infer cool stuff from it. It's a bit of a contrived example, albeit one that is based in code that I've seen in the wild (in cal.com's repo, for instance). It's really a way of setting up exercise 4 and 10.
Also, doing it my way means that the resulting type (if you don't pass a type argument) is unknown, not any, which is more type-safe.
@@mattpocockuk i think what threw me off a bit is that these two functions are directly below eachother. Thinking about it more, make fetch is probably some sdk you import to get data (so something the libary auther writes), and you use the generic function argument to type your output. looking at it like this it makes sense ofc to do it your way - and you are right, there are examples all over (for example the pockerbase javscript sdk). thanks for the reply.
Is there any difference between (...args: any) => any and () => any for TypeScript?
Yes, the first one indicates any number of parameters. The second indicates no parameters.
@@mattpocockuk for some reason I was sure that (a: number) => {} was assignable to () => void type, but it's not (luckily).
@@rafadydkiemmacha7543 Pretty sure it is, unless I'm misunderstanding
Thank you so much man you are great, bless you.
I am really glad that I started my javascript journey with Typescript. Thank you so much for the video.
Legend! thanks mate, the best of the best of the best :) 🙏🏼
let me grab a beer to make my fears go away and jump fully into this, is ok to have fear, but I need to face it
Always A+ content. Thanks for this!
@Matt how do you debug with comment line ? (something like `// ^?`) Looks like very useful
hsy did you ever find the answer to this?
@@archengell ua-cam.com/video/u0adKDu--cA/v-deo.html
Very curious
@@otiamaino2461 and @arkitekos Matt made a video just about that ua-cam.com/video/u0adKDu--cA/v-deo.html
This seems like a more powerful form of destructuring, where instead of presetting the initial values, you enforce the types that should be returned.
You are so cool while explaining!!!
Sometimes `as` is unavoidable indeed, but your example is dangerous. You can easily use it in typed function like `type TA = { a: number }; function getAProps(a: TA) { return typedObjectKeys(a); }` and its result will be typed as `"a"[]` but you could put a value of some type that extends TA as an argument, like `const b = { a: 2, b: 3 }; getAProps(b);` and get `["a", "b"]` result wrongly typed as `"a"[]`.