The generic component example was good but I find using compound components a much pleasant approach, you don't have to worry about passing types and the components end up being completely modular because you can pass whatever you want.
5:38 I'm pretty sure you don't have to pass the type to the carousel. So the it can be {item.id} item will still be infered correctly here from the type you're passing in the items and renderItem will still have that type set correctly.
Would make a lot more sense to just let the Carousel receive children and just render them along with the buttons to be honest. That way you don't even have to care about what types you're working with as the Carousel never actually interacts with them, it's only responsible for placing them where they belong. PropsWithChildren is enough. Something noteworthy about that type is that the children are actually optional; this is intentional, but could be a bit counterintuitive for those unaware. If the children should be required, a custom type should be used for that. type PropsWithRequiredChildren = PropsWithChildren & { children: ReactNode }; Something like that'd probably work quite well, but I haven't tested it and I usually don't even use TypeScript, so my skills are a bit rusty. I use JSDocs for the most part as we don't use TypeScript at work, does the job just as well most of the time so I rarely miss TypeScript.
Wow what an explanation along with easy examples. After watching this video, I am thinking like I know nothing. But now I will not make those mistakes again. Thanks for this awesome video.
Render props are only adding indirection in your carousel examples. You really only need to force render props if you need access within the component to those props and there's usually a better design pattern available. In this case you could have just rendered children and had the carousel dictate the container, and its styles, within the carousel.
children is optional in PropsWithChildren, so that can be a big gotcha if people aren't aware of it, as you'll receive no warnings about it. So explicitly declare the children as required if necessary.
Instead of a generic component, you can have a component which interface accepts a generic thus you can pass that generic to the underlying props, a bit better syntax IMO
Hi @CoderOne, I really love your content. One off topic: could you maybe share your theme and font setup? I really like the style of your IDE. That'd be awesome!
Thanks brother! I want to ask what is the name of theme you are using here? and what's the extension you used to get a pen to highlight under code snippets?
Thanks for the great content, I have a question about the last event type one. I can't see the difference of have the type beside the event or after the function name. Can you let me know what is the benefits to have the type after the function name?
A lot of these things can be used with JSDoc as well, not just TypeScript. Generics is not possible, only kind of, but pretty much everything else works somewhat.
You can definitely tell that React was invented in a world where TypeScript didn't exist, and so much of the typing for it feels awkward and bolted on.
Confused about ComponentProps. If you create a div with a className prop, click on it with "CMD" button you'll be sent to interface with HTMLAttributes. I've checked what is ComponentProps and it mostly the same, but with ref and key props. But key will not be passed into child component. And the right way to use ref is wrap your component with "forwardRef". So finally.. while TS shows HTMLAttributes on div props, isn't it better to use it?
The type vs interface debate has already been resolved by Matt Pocock of Total TypeScript. He's already proved in a video that interfaces resolve during compile time much faster than types, which is a big argument in favor of using interfaces unless you really need the features that types provide, such as discriminated unions, utility types, etc.
@@BeeBeeEightthat’s not what the argument has been about. Types can do everything that interfaces can, and then a lot more. Interfaces are mutable, which can be very bad depending on what you’re doing.
The generic component example was good but I find using compound components a much pleasant approach, you don't have to worry about passing types and the components end up being completely modular because you can pass whatever you want.
5:38 I'm pretty sure you don't have to pass the type to the carousel. So the it can be {item.id}
item will still be infered correctly here from the type you're passing in the items and renderItem will still have that type set correctly.
Would make a lot more sense to just let the Carousel receive children and just render them along with the buttons to be honest. That way you don't even have to care about what types you're working with as the Carousel never actually interacts with them, it's only responsible for placing them where they belong. PropsWithChildren is enough. Something noteworthy about that type is that the children are actually optional; this is intentional, but could be a bit counterintuitive for those unaware. If the children should be required, a custom type should be used for that.
type PropsWithRequiredChildren = PropsWithChildren & { children: ReactNode };
Something like that'd probably work quite well, but I haven't tested it and I usually don't even use TypeScript, so my skills are a bit rusty. I use JSDocs for the most part as we don't use TypeScript at work, does the job just as well most of the time so I rarely miss TypeScript.
Thanks bro, the first example opened the door to my new world.
Wow what an explanation along with easy examples. After watching this video, I am thinking like I know nothing. But now I will not make those mistakes again. Thanks for this awesome video.
great video. I think I will often come back to this video.
Render props are only adding indirection in your carousel examples. You really only need to force render props if you need access within the component to those props and there's usually a better design pattern available. In this case you could have just rendered children and had the carousel dictate the container, and its styles, within the carousel.
const Component: FC No need explicitly declare children in your props.
children is optional in PropsWithChildren, so that can be a big gotcha if people aren't aware of it, as you'll receive no warnings about it. So explicitly declare the children as required if necessary.
Instead of a generic component, you can have a component which interface accepts a generic thus you can pass that generic to the underlying props, a bit better syntax IMO
Hi @CoderOne, I really love your content. One off topic: could you maybe share your theme and font setup? I really like the style of your IDE. That'd be awesome!
Thanks!
Theme: Halcyon
Font (VSCode Default): Menlo, Monaco, 'Courier New', monospace
Thanks brother! I want to ask what is the name of theme you are using here? and what's the extension you used to get a pen to highlight under code snippets?
Very informative video ❤
Thanks for the great content, I have a question about the last event type one. I can't see the difference of have the type beside the event or after the function name. Can you let me know what is the benefits to have the type after the function name?
Hi CoderOne~ Great video! Would you mind share what app you used in the video to do the fancy drawing?
A lot of these things can be used with JSDoc as well, not just TypeScript. Generics is not possible, only kind of, but pretty much everything else works somewhat.
do we still need to add React.FC for component??i was removed it all from my previous project.
this is very nice, thank you
You rock it. Thnx
You can definitely tell that React was invented in a world where TypeScript didn't exist, and so much of the typing for it feels awkward and bolted on.
thank you bro
how is the extension for vscode called which hides the tailwind code in editor? looks really clean - need this. thanks
Tailwind fold
thanks@@CoderOne
Confused about ComponentProps. If you create a div with a className prop, click on it with "CMD" button you'll be sent to interface with HTMLAttributes. I've checked what is ComponentProps and it mostly the same, but with ref and key props. But key will not be passed into child component. And the right way to use ref is wrap your component with "forwardRef". So finally.. while TS shows HTMLAttributes on div props, isn't it better to use it?
The key attribute will never be passed to any component as that is reserved by React itself for rendering lists.
@@CottidaeSEA That's I'm talking about. No reason to use ComponentProps, because it is extended from HTMLAttributes, but have key and ref
If you want to follow the SOLID principle, I feel like the 3rd example violate the OCP of SOLID
How do you do it with "type" INSTEAD of interface?
what vs code theme is that?
Links are not in the description
Added! Thanks for mentioning it.
Why r u using interfaces and not type declarations
Why not?
The type vs interface debate has already been resolved by Matt Pocock of Total TypeScript. He's already proved in a video that interfaces resolve during compile time much faster than types, which is a big argument in favor of using interfaces unless you really need the features that types provide, such as discriminated unions, utility types, etc.
@@BeeBeeEightthat’s not what the argument has been about. Types can do everything that interfaces can, and then a lot more.
Interfaces are mutable, which can be very bad depending on what you’re doing.
@@BeeBeeEight its just a lie
Both works well. Types are more advanced compared to interfaces, but in our case, they both can do the job well.