Another Typescript type, which is not included in the video, is the Pick type, which is the opposite of Omit. Instead of Omitting the property, you include the properties to be picked.
Man, there's a LOT of information in here I never even heard of, but is pretty much exactly what I need, super cool. This would be a great video to add chapters to btw: 0:00 Intro 0:18 typeof / keyof 1:21 ReturnType / Awaited 2:59 Prettify (and nesting) 4:07 Partial / Required 5:58 Omit / Exclude
The exclude util is not necessarily used for more complex types. It's for excluding types from union types in general instead of omitting props from an object type. So you could also use it to exclude e. g. string literals
updateTodo example has a bug... you need to prefix fieldsToUpdate with ... if you want to override the todo, otherwise you will create an object with additional fieldsToUpdate property, which contains the values that should be used for updating.
I'll never understand why interfaces hide their fields like it's something shameful lol. That Prettify type will save millions of developers including me.
It used to be that way. But people complained that it is confusing and convoluted to see the result of the union when a union of preexisting types is made, instead they wanted to see which types the union is made of.
@@Netrole what hellll. i think would be pretty usefull show the type and your fields. Like: title: string; description: string; role: Role < { name: string, i id: number } >
There's one thing I don't understand. Why do you put an empty object with Prettify's '&'? Wouldn't you get the same result without using the & operator...? I'm really curious! 😭
I’m a bit confused when writing a function in TS aren’t we meant to declare the return type in the function declaration? When would you need to infer the return type??
This question is kind of backwards. Why would you want to define it? If you can infer it, the types are done. Your code defined them. Manually defining is redundant extra work. There are cases where you might not want to infer them, but those are the ones you'd need reasons for, which is the opposite of your question.
Let’s assume there is a function that returns an array of some kind of ingredients. In useState you want to declare that you want to keep array of some ingredients, but you start with an empty array. How to type the useState without knowing the return type of that function if you don’t wave the type specified elsewhere? It looks like an edge case but I can see a need for it sometimes
@@DavidWMiller no lol, declaring the return type is beneficial because a reader can see what the function returns without having to interpret the function.
I wonder IS prettify could make typescript faster. Maybe not self implemented but As A buildin type. Because of then could avoid looking up complex structures.
This is not good. We are adding production code to augment IDE assists. I get why it exists, but this is something that should be supported by TS and the tool chain by default.
Just so y'all know: These things are just to "cope" with "inherited" old code. If you have any respect for your job and your future, you definitely should learn some architectural skills. Cheers
can you please, pretty please, extremely please... not pronounce OUR as or and more like hour? (just phonetically like a-uaer, and not o-ur ... I don't know whay is this so annoying to me... but drives me nuts :)
I'll always appreciate these TS videos any day of the week
The Prettify type should not exist. It should be a typescript configuration option.
it is good until you are really need to have an object
The semantics of what the higher level types are defined as is relevant information.
Another Typescript type, which is not included in the video, is the Pick type, which is the opposite of Omit. Instead of Omitting the property, you include the properties to be picked.
Man, there's a LOT of information in here I never even heard of, but is pretty much exactly what I need, super cool. This would be a great video to add chapters to btw:
0:00 Intro
0:18 typeof / keyof
1:21 ReturnType / Awaited
2:59 Prettify (and nesting)
4:07 Partial / Required
5:58 Omit / Exclude
The exclude util is not necessarily used for more complex types. It's for excluding types from union types in general instead of omitting props from an object type. So you could also use it to exclude e. g. string literals
One of the rare examples where a rather clickbaity sounding video really delivers 👍
updateTodo example has a bug... you need to prefix fieldsToUpdate with ... if you want to override the todo, otherwise you will create an object with additional fieldsToUpdate property, which contains the values that should be used for updating.
Great explanations, very well illustrated. Thanks
Wow! These are good TypeScript tips. Thank you!
I'll never understand why interfaces hide their fields like it's something shameful lol. That Prettify type will save millions of developers including me.
Bc it’s and interface 😂 not and object…
Javascripters trying to understand object orientation.
It used to be that way. But people complained that it is confusing and convoluted to see the result of the union when a union of preexisting types is made, instead they wanted to see which types the union is made of.
@@Netrole what hellll. i think would be pretty usefull show the type and your fields.
Like:
title: string;
description: string;
role: Role <
{ name: string, i
id: number }
>
it is useful in creating branded type
Really nice, short but with so many good and important things video.
Great stuff Josh! Please never stop posting new content!
These are super cool tips. Thank you for sharing them
We need more videos like these!! Great video buddy
There's one thing I don't understand.
Why do you put an empty object with Prettify's '&'?
Wouldn't you get the same result without using the & operator...?
I'm really curious! 😭
Fantastic video, simple, well explained and to the point. Great examples 👍
Thanks Josh 🙌
thanks a lot , we are constantly learning from your videos ! ,keep going
So useful thank you!
Super helpful! Thank you :)
Wow! Thanks, Josh 🍻🍻
thank you
let God bless you for your kind activity
Do you mean no matter how nested they are or no matter the number of Joins? Great video btw
About Exlude is mind-blowing! Tnx
Amazing tips!! Thx a lot!
The best thing i have learnt today
This helped me a lot, Thanks !
I wonder will you have a video about a project with bun?
Prettify is very good, nice tip.
Thanks Josh helps alot for us :D
That's tips & tricks of Ts is time saving❤
Thanks buddy 😊
Nice one ! Thanks !
Our brother always take us from darkness to light .
Thank you Josh 🙏
This tutorial is valuable
Great types, you just forgetting `Pick` 👀
This is more complex than learning rust or c or go. Anyway great video :)
Great content :) I ❤ typescript
Yep, nice!! Thanks heaps!
I’m a bit confused when writing a function in TS aren’t we meant to declare the return type in the function declaration? When would you need to infer the return type??
This question is kind of backwards. Why would you want to define it? If you can infer it, the types are done. Your code defined them. Manually defining is redundant extra work.
There are cases where you might not want to infer them, but those are the ones you'd need reasons for, which is the opposite of your question.
Let’s assume there is a function that returns an array of some kind of ingredients. In useState you want to declare that you want to keep array of some ingredients, but you start with an empty array. How to type the useState without knowing the return type of that function if you don’t wave the type specified elsewhere? It looks like an edge case but I can see a need for it sometimes
@@DavidWMiller no lol, declaring the return type is beneficial because a reader can see what the function returns without having to interpret the function.
@@gnack420Typescript shows you the inferred type when hovering the function name. No need for reading the code
@@diegofernandocobacruz6508 The IDE does that, not TypeScript. Open it on a notepad and hover it over.
Very useful!
Prettify is now a vscode extension
Great video as always
great stuff Josh!
Exclude is not for complex types but unions.
3:45 Matt Pockock is a TS Ninja. He has a great channel. So as I understand he contributed to TS and created this type?
5:46 Errr... and what will be the return type of updateTodo again? 😝
Looks like somebody forgot another spread operator: ...fieldsToUpdate
You should have added Pick as well since you showed omit
Very helpful 🔥
Very greate video thanks
I wonder IS prettify could make typescript faster. Maybe not self implemented but As A buildin type. Because of then could avoid looking up complex structures.
I think you can replace all "interface" with "type"
awesome pretty helpful!
Josh, would be great if you make a video about the skills a junior developer should have to get their first job. THANKS 4 all your content.
Do u think ai will replace us one day
Being mainly a Swift developer I'm left shocked by TypeScript versatility
It is usefull to me thanks!
This is not good. We are adding production code to augment IDE assists. I get why it exists, but this is something that should be supported by TS and the tool chain by default.
thats true
one thing that can be done is "tsc --noEmit --incremental --watch" and that at least shows the errors in the console
great video!
I won't you won't over
type Person = keyof typeof obj
type Return = ReturnType
Partial
Required
type Omitted = Omit
Master
Fuck yea
Nice one ☝️
The first example doesnt make a lot of sense. Why would you want Person to be either the string literal "name" or "age"
It's just an example probably not the best one. But is super handy when you want to keep track of all keys within an Object or Enum
@@IneyeGabriel I know the feature is useful, but the example makes it more confusing
prettify is good one
ReturnType
Awaited
Partial
Required
Omit
Exclude
Just so y'all know: These things are just to "cope" with "inherited" old code. If you have any respect for your job and your future, you definitely should learn some architectural skills. Cheers
Good content, but you need to slow down with the delivery.
I'm an expert at other languages but only just kept up with it.
this is good to know, but you don't need any of this besides making things more complex and harder to debug.
& {} wtf
can you please, pretty please, extremely please... not pronounce OUR as or and more like hour? (just phonetically like a-uaer, and not o-ur ... I don't know whay is this so annoying to me... but drives me nuts :)
Aaaaand the prettify type was fake :/
sorry but this is not a high quality content...
sorry but this is not a high quality comment
That Prettify type makes the video high quality
Like every developer finds a bug once in a while 😂