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.
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.
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.
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.
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!
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
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.
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.
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.
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?
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.
@@Thassalocracythat’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.
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?
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?
