No worries! Very well done video. Very informative. There's a lot of beginner content on RUclips but not as much architectural content, so I really appreciate you sharing your take on the subject. Just subscribed! Looking forward to more of this kind of content 😁
I've been using the compound component pattern for a while and this is a great visual explanation of the benefits and how it's implemented. The pattern is a good example for Separation of Concerns / SOLID principles - Single responsibility, Open-Close, Dependency inversion.
What a great way to group components and their relevant data. I've been using React in production for nearly a year now and it never occurred to me to use a Context at this deep level before. Really good video, thanks for sharing!
Same here, using Context at deep level sounds like a nice idea. But as many others have pointed out, it comes with its own challenges of tightly coupled component that could have been mistaken for "NOT TO BE REUSED AT OTHER PLACES".
This video has insane value. I'm working on my own web app, and this concept, when well applied and in the right situation, is a game-changer. The code without it, turns out to be simply a mess, but when applied properly, it provides the exact modularity needed. Awesome!
Man keep these types of videos coming and you will be one of the top TS/React youtubers in no time. I would like to ask for the next videos if you could dive deeper into the pros or cons. Thanks and best of luck! :)
what in the world, it is like a magic to me, gonna deep dive to get a better understanding so I hope i can implement it in my use case. thanks A LOT man!
Really clean video, showed the process really well. I think the really great thing about this approach is that you can easily create variants. It is really good if you need to use the same code base to support multiple clients for example.
Hey Vincas, I just wanted to let you know that this was a masterful lecture, and really informed my coding style! I'll be writing a small storybook component library for my startup this week and your patterns have really shaped the approach I wanna take. So thank you for providing such high-quality instruction! Secondly, I just wanna point out for anyone that uses NextJS *13* that context is a client side feature, and will not work without the "use client" directive at the top of the file. This also means that if you want to fetch data server side, say in an async function, you will probably need to have a state initializer component that can interface between the server and client. Jack Herrington (author of No BS TS -- and he has a RUclips channel under his name) has a video going over state management in NextJS 13 to cover this topic. Again, Vincas, I really appreciate this! Thanks, and greetings from the US 👋🏽 Subbed.
I see this composition pattern in the MUI implementation, personally I think this may suite for base components with infrequently change structure. Suppose your Card component need modifying to grid style, it's hard to maintain both `slot` styles and props-components styles. Another problem is manage reference of slot props, which can lead to performance issues, but if you using old class component with some properties like `renderImage`, `renderRating`, etc, this is a good way to simplify your component.
@@davien001 Yes it would, but at the same time you will have to maintain multiple memos instead of having a single memoization step for the entire component.
danggg it! I've seen this pattern started from headless-ui a couple years ago and nowadays as my experience increases, I see a lot more, the most recent is radix-ui which I (we) love hahaha I try to learn this kind of approach back then from headless-ui, sadly I understand nothing, lol. A couple years later, I try to learn again from headless-ui and radix-ui, then your video showed up at the very right time. thank you for making a very clear tutorial and a good example whereas this kind of card can be very complex at some point. I really enjoy watchin this video a couple of times. Thanks! 🙌
10 seconds in and I’d already subscribed! Really liked this tutorial, looking forward to your future content. RUclips needs a lot more React design pattern videos like this.
i really dislike this sort of composition. i call it fake composition. the internal components are just a longer way of specifying props (as opposed rendering something). - components become 10X more complex because of the need to maintain a context and everything around it. - zero type safety. which components are allowed inside? is the order important? how about nesting? - because of the type safety thing, you need to maintain docs for the thing. instead of just asking TS to let you know which props it accepts.
This comment is underrated. You also turned each of these components required to be used within a context. Instead of using props, makes the sole use of the component to be within the product card component. It its also very hard to test, as you need to mock a context in order to be able to test the components instead of simple passing props to the components youre testing. Props > context api. This is simply over engineered
@@ChristianMoentest Valid point, and I do not advice using this pattern everywhere. It's very helpful for building design systems, especially public libraries as this prevents unintended usage and simplifies the API for the user. The testing is indeed a bit harder, though I don't see much point in testing the sub-components individually as small and simple as they usually are.
@@codevincas So for me, a real composition would be something like Settings. If the internal components are just a fancy way to set props it's just an over complicated configuration method IMO.
1. How do they become more complex? You create a context and wrap a Root component around the Provider. You can create all your components in a single file-is it really that hard to maintain a scoped context? 2. Why does it matter which components are allowed? Order shouldn't be important. You're creating arbitrary restrictions that makes it harder to reuse for other cases. You're making up an API which takes _more_ effort to implement than just accepting any component. If your intent is to map over the children to stuff props onto them or filter out, then don't. That's what compound components solve for you. Compound components makes decisions easier at the consumer level, rather than implementation level, making them great for reusability. 3. I don't get this. The compound component is just a component built up of other components, whether it provides a context or not. Each component defines their own props. That said, this is by no means a recommendation that you should make everything a compound component. It's still more effort than just making a special-case component that does what it needs. However, they are a great abstraction when you want more flexibility without imposing restrictions and unnecessary implementation details.
Nice video! I like the demonstration of Component Composition and also the "name-spacing", however, I wouldn't agree with the use of Context API here: Firstly, in the first part of the video you show how to make the component more reusable with Component Composition, but then with the Context API you introduce maximum-tight coupling to the Context, which arguably impedes the reusability. Secondly, in a way, I'm thinking Context API is just "hidden" prop drilling where the dependency isn't visible at first sight, which might not be ideal in terms of readability for other developers.
Correct, also gosh !! if anyone is using vanilla js with react good luck accessing/handling those product attributes after change in product's attributes.
Agreed, I'm definitely going to apply the idea about Component Composition, but the rest of the video sounds like it's better for demo projects to look as "clean" as possible rather than for real-world code. I'm more likely to use , and and other similar lower-level components as children rather than , and . It's a lot more flexible and it's still very readable.
I kinda agree with the use of Context API here. I would much rather the thing using these components to pass down the data to each child component itself instead of giving the data to the component to then pass to the children, since it gives a lot more flexibility and makes the code easier to grok. In my mind, Context would be better used for avoiding prop drilling of inherent properties of which the child elements might need. For instance, maybe is clickable where it then folds any elements when clicked, so it could then put that into Context which then uses. Whilst you can handle this in the thing that's calling , being a visual bit of logic, it makes a lot of sense to keep that in itself. I also prefer to empower the users of these components to be able to use them however they want. So if they want to use elsewhere, then let them do that since they might have a use-case I didn't think of.
This was very helpful and informative! I have a couple of questions if you have time to answer: 1. Why does use slot props as opposed to only "children" like the compound components? 2. Are there concerns about bundle size when using compound components since you're always importing all of them?
old comment but I'm guessing slots restricts the order of components or DOM structure (ie image on top, info in the middle, cta button on the bottom) based on ProductCard's implementation while children have more wiggle room
Great video! I can't to help but to ask why do you think this is a good approach? When in fact we can make the component accept one prop, and object with all the data necessary to render the component.
You could, and for most components that's totally acceptable, and anything more would be overengineering. As I mentioned in the beginning of the video - what happens when you want to slightly change the appearance of the component, for instance hide some parts of it or add a small bit of logic? You'd add boolean flags and change the component implementation logic to accommodate for them. That's fine while there aren't that many flags - most components never reach that point, so that's ok. But particularly design system components are often used in multiple different ways with slight tweaks for each use case. In that case changing the implementation of the component becomes risky and cumbersome, also the component's implementation logic would grow to support all those different use cases and the prop list would be mostly a bunch of boolean flags. Just passing in an object doesn't help in that case, because it doesn't change the need for those flags and in many cases design system components won't even be using a domain model (the object), but rather generic props to retain flexibility. In that case, composable components are superior. If you want to use the context and compound components - that's your decision, in many cases it would be over-engineering, but in some, they're a nice way to group components together.
I didn't quite understand what are the benefit of passing the image, info and action components vs adding them inside the ProductCard once you've already implemented the context. Wouldn't it be simpler? you'll just have to pass the product as prop and the components inside the ProductCard would get that through the context.
The "slots" is a way to delegate the layout/design decisions to the user of the ProductCard. Without them you'd have no way to make certain parts invisible, reorder them or extend the component easily (without changing the implementation). Basically, this improves flexibility by making the component composable, and the context is just a bit of sugar on top, to reduce the amount of props that need to be passed around.
@@codevincas The props does not delegate those decisions to the user but to the ProductCard itself-you exactly need to change the implementation of ProductCard because it takes those props. What Prizel is saying is that you could make ProductCard component itself take those compounds as children, since it already provides the context for those components to consume, then pass the product as a prop to the ProductCard. You'd now have even more flexibility over the layout. Even better, you could use the Radix UI Slot component to further allow other types of user-defined components that will merge its props into the immediate child component. This is a, arguably, better way of handling custom components instead of dealing with `as`/`component` props that otherwise are hard to create types for.
would it also make sense to put the subcomponents as default values for the Product props and allow them to be nullable, so you would get a default Product which is used most often and you don't have to compose it every time, but you still retain all of the flexibility when you need to have special cases
There's nothing stopping you from doing that, though I would probably create wrapper components for different use cases instead, and leave the composable components as a lower level API.
Let's see if I understood correctly the right use cases of this: I should/could use this whenever I have a component that needs some more details, but those details alone wouldn't be something that I could reuse elsewhere Seems like this, am I right? :)
Sam Selikoff has a great set of videos on implementing RadixUI components which follow a similar design. In fact, once I saw the end result of using the Context API to make the components modular I couldn’t help but think I had seen it somewhere before. It was a great video and I learned a lot! Subbed 😊
I would like to follow over your video from the initial code. I'd like to follow along while watching the video, starting from the initial code. Could you possibly provide the initial code too?
Thank you for the video. You can achieve namespacing by perhaps importing everything on a separate file as non default exports if the issue at hand is too many lines of imports. I will personally always favour to as on the latter you're creating a data dependency where the first one you can easily erase Product and will still exist. You could then import everything in one line.
This is a good pattern to use, especially for low level components. prefer slots over props to keep the code of the component easy. Another suggestion i would give is to make the components do as little as possible, whatever you are not sure is not going to be reused most of the times should stay in the parent, i think a common mistake is to pass the options props to a Select component, but the options may be in many format, value-label, value-label-andLotOfOtherStuff, maybe you don't even need the label because you are showing a bunch of icons, also the options may come from an API or may be filterable, and the filtering logic may vary, etc. So just move the handling of the options and the selection of the value in the parent and it will simplify the code of the Select greatly, while the code in the parent would be easy to understand because it will be very specific for that Select.
Hey,, excellent video! Just a quick question. Let's imagine that you have to render 100 ProductCards. In that case, would you create 100 Context for each card? Thanks!
I myself, prefer to develop components so they're easier to use consumer side, I feel like providing variations of a component as a prop is much easier, pass through an Id for the product, and have all logic relating to fetching and deciding layout to the component, learning curve for other developers is much nicer, and you're using the same composition in every place, it makes it much harder to fix bugs or make changes, where if it's inside the component, maintenance is much easier, you end up having to create wrapper components too many times with composition too so that things are reusable
Very good content! As some people already pointed below, you need to work on the editing. I know it is hard, but this type of things helps to understand better your content.
Hi! Excelent video, but I have a question, React recommends to use Component Composition every time it's possible and avoid (as much as you can) the use of ContextAPI (Re rendering problems). Will you use Context in a real app in the way you are showing right now? Thanks.
Huh, it works well for me, but I notice that StackBlitz is not booting up the demo on Mobile and Incognito mode - maybe that's what's happening for you?
Question, wouldn't it be better to pass the Compound Components as children? In this use case, it would require one new Component, ProductCardBottom, to wrap info and action sections.
You absolutely can, in fact I would strive to do it this way if you can. It's not always simpler or possible to do it this way though, especially for non-design system components (when they need this kind of flexibility).
This actually is opposite of monkey patching, because you don't need to touch implementation of ProductCard to extend it. If the sub-components are bothering you, you can always create a wrapper with props - just like in the beginning. That's the flexibility composition gives you!
Thank's for the answer. What I mean is I do not want to mutate the object ProductCard, not its implementation. Since the patch is done in a separate file, there is now way of knowing where ProductCard.x comes from (except with folder structure and naming conventions, but that is not enough of a guarantee for me). I was wondering what would the best way of extending the ProductCard object in the same way, but from the root file, so that all the existing subcomponents are visible when reading the main component file. Also, does the linter manage that stuff well?
Nice video! Quick suggestions: 1. Add ambient music in the background to make it more immersive while watching 2. Make the video more about the topic and example code by having snippets ready to paste than typing manually 3. Could work on some tone modulations while explaining i.e varying intensity, some animations, etc. Watch Hyperplexed on YT as he grew very quickly due to loopable content. Good luck!
Thanks for the comment, I might add BGM in the next video and I do need to work on the smoothness of my talking, but it will come with practice I hope. I'm experimenting with different ways to present code atm, will try to do some copy-pasting in some sections for longer videos, or edit out the typing part. Hyperplexed is next level stuff, he's not doing long-form tutorials, but is definitely inspiring though.
1. I'm actually quite happy there's not background music. If I wanted any, I'd play my own 😅 2. As the typing has roughly the same duration as the explanations... I think they match well.
Sorry for the gaps from 4:56 to 5:00 and 5:05 to 5:09, editing fail, will try to double check better in the future 🤦♂
No worries! Very well done video. Very informative. There's a lot of beginner content on RUclips but not as much architectural content, so I really appreciate you sharing your take on the subject. Just subscribed! Looking forward to more of this kind of content 😁
You realise you can cut the gaps out in the RUclips creators studio without any need to reupload, don't you?
So I'll just ... children. 😁
That's exactly what I've been looking for!
Thank you man! Please don't stop posting videos, I'd rather watch your tutorials than netflix
I've been using the compound component pattern for a while and this is a great visual explanation of the benefits and how it's implemented.
The pattern is a good example for Separation of Concerns / SOLID principles - Single responsibility, Open-Close, Dependency inversion.
What a great way to group components and their relevant data. I've been using React in production for nearly a year now and it never occurred to me to use a Context at this deep level before.
Really good video, thanks for sharing!
Same here, using Context at deep level sounds like a nice idea. But as many others have pointed out, it comes with its own challenges of tightly coupled component that could have been mistaken for "NOT TO BE REUSED AT OTHER PLACES".
This video has insane value. I'm working on my own web app, and this concept, when well applied and in the right situation, is a game-changer. The code without it, turns out to be simply a mess, but when applied properly, it provides the exact modularity needed. Awesome!
This code looks so clean! I love refactoring code videos
Very nice! I never thought of using the context API like this, this is super useful, thanks!
Awesome, glad it was useful 👌
This looks like a very fun pattern to use. At first I was not sold on the whole namespace thing with Component.Name but it grew on me.
Man keep these types of videos coming and you will be one of the top TS/React youtubers in no time. I would like to ask for the next videos if you could dive deeper into the pros or cons. Thanks and best of luck! :)
what in the world, it is like a magic to me, gonna deep dive to get a better understanding so I hope i can implement it in my use case. thanks A LOT man!
this type of react content is lacking on youtube. Make some more my man!
Really clean video, showed the process really well. I think the really great thing about this approach is that you can easily create variants. It is really good if you need to use the same code base to support multiple clients for example.
nice code, but how is the performance if you have a lot of card (contexts)?
Hey Vincas, I just wanted to let you know that this was a masterful lecture, and really informed my coding style! I'll be writing a small storybook component library for my startup this week and your patterns have really shaped the approach I wanna take. So thank you for providing such high-quality instruction!
Secondly, I just wanna point out for anyone that uses NextJS *13* that context is a client side feature, and will not work without the "use client" directive at the top of the file. This also means that if you want to fetch data server side, say in an async function, you will probably need to have a state initializer component that can interface between the server and client. Jack Herrington (author of No BS TS -- and he has a RUclips channel under his name) has a video going over state management in NextJS 13 to cover this topic.
Again, Vincas, I really appreciate this! Thanks, and greetings from the US 👋🏽 Subbed.
Thank you! You should also take a look at Radix to see how a similar approach is used in practice.
Great video. Not 100% sold on it all being a best practice, but really useful for everyone to understand how it works
I see this composition pattern in the MUI implementation, personally I think this may suite for base components with infrequently change structure. Suppose your Card component need modifying to grid style, it's hard to maintain both `slot` styles and props-components styles.
Another problem is manage reference of slot props, which can lead to performance issues, but if you using old class component with some properties like `renderImage`, `renderRating`, etc, this is a good way to simplify your component.
I'm just learning React but wouldn't memo solve those performance concerns you talked about?
@@davien001 Yes it would, but at the same time you will have to maintain multiple memos instead of having a single memoization step for the entire component.
danggg it! I've seen this pattern started from headless-ui a couple years ago and nowadays as my experience increases, I see a lot more, the most recent is radix-ui which I (we) love hahaha
I try to learn this kind of approach back then from headless-ui, sadly I understand nothing, lol. A couple years later, I try to learn again from headless-ui and radix-ui, then your video showed up at the very right time.
thank you for making a very clear tutorial and a good example whereas this kind of card can be very complex at some point. I really enjoy watchin this video a couple of times.
Thanks! 🙌
10 seconds in and I’d already subscribed! Really liked this tutorial, looking forward to your future content. RUclips needs a lot more React design pattern videos like this.
Really great concept that can actually be applied to almost any front-end framework that's out there today, thanks for sharing!
i really dislike this sort of composition. i call it fake composition. the internal components are just a longer way of specifying props (as opposed rendering something).
- components become 10X more complex because of the need to maintain a context and everything around it.
- zero type safety. which components are allowed inside? is the order important? how about nesting?
- because of the type safety thing, you need to maintain docs for the thing. instead of just asking TS to let you know which props it accepts.
What is the real composition?
This comment is underrated. You also turned each of these components required to be used within a context. Instead of using props, makes the sole use of the component to be within the product card component. It its also very hard to test, as you need to mock a context in order to be able to test the components instead of simple passing props to the components youre testing.
Props > context api.
This is simply over engineered
@@ChristianMoentest Valid point, and I do not advice using this pattern everywhere. It's very helpful for building design systems, especially public libraries as this prevents unintended usage and simplifies the API for the user. The testing is indeed a bit harder, though I don't see much point in testing the sub-components individually as small and simple as they usually are.
@@codevincas So for me, a real composition would be something like Settings. If the internal components are just a fancy way to set props it's just an over complicated configuration method IMO.
1. How do they become more complex? You create a context and wrap a Root component around the Provider. You can create all your components in a single file-is it really that hard to maintain a scoped context?
2. Why does it matter which components are allowed? Order shouldn't be important. You're creating arbitrary restrictions that makes it harder to reuse for other cases. You're making up an API which takes _more_ effort to implement than just accepting any component. If your intent is to map over the children to stuff props onto them or filter out, then don't. That's what compound components solve for you.
Compound components makes decisions easier at the consumer level, rather than implementation level, making them great for reusability.
3. I don't get this. The compound component is just a component built up of other components, whether it provides a context or not. Each component defines their own props.
That said, this is by no means a recommendation that you should make everything a compound component. It's still more effort than just making a special-case component that does what it needs. However, they are a great abstraction when you want more flexibility without imposing restrictions and unnecessary implementation details.
Nice video! I like the demonstration of Component Composition and also the "name-spacing", however, I wouldn't agree with the use of Context API here: Firstly, in the first part of the video you show how to make the component more reusable with Component Composition, but then with the Context API you introduce maximum-tight coupling to the Context, which arguably impedes the reusability. Secondly, in a way, I'm thinking Context API is just "hidden" prop drilling where the dependency isn't visible at first sight, which might not be ideal in terms of readability for other developers.
True, this and hidden data flows are the reason I tend to avoid the Context API.
Correct, also gosh !! if anyone is using vanilla js with react good luck accessing/handling those product attributes after change in product's attributes.
Agreed, I'm definitely going to apply the idea about Component Composition, but the rest of the video sounds like it's better for demo projects to look as "clean" as possible rather than for real-world code. I'm more likely to use , and and other similar lower-level components as children rather than , and . It's a lot more flexible and it's still very readable.
Context helps those composition components which are grouped and enter linked like Select & Option.
I kinda agree with the use of Context API here. I would much rather the thing using these components to pass down the data to each child component itself instead of giving the data to the component to then pass to the children, since it gives a lot more flexibility and makes the code easier to grok. In my mind, Context would be better used for avoiding prop drilling of inherent properties of which the child elements might need. For instance, maybe is clickable where it then folds any elements when clicked, so it could then put that into Context which then uses. Whilst you can handle this in the thing that's calling , being a visual bit of logic, it makes a lot of sense to keep that in itself.
I also prefer to empower the users of these components to be able to use them however they want. So if they want to use elsewhere, then let them do that since they might have a use-case I didn't think of.
FINALLY. I needed to know how headlessUI makes their components thanks ALOT
I like how you always type 'Node' as 'NOde' haha
This was very helpful and informative! I have a couple of questions if you have time to answer:
1. Why does use slot props as opposed to only "children" like the compound components?
2. Are there concerns about bundle size when using compound components since you're always importing all of them?
old comment but I'm guessing slots restricts the order of components or DOM structure (ie image on top, info in the middle, cta button on the bottom) based on ProductCard's implementation while children have more wiggle room
👏👏more content like that!
Great explanation
Great video! I can't to help but to ask why do you think this is a good approach? When in fact we can make the component accept one prop, and object with all the data necessary to render the component.
You could, and for most components that's totally acceptable, and anything more would be overengineering. As I mentioned in the beginning of the video - what happens when you want to slightly change the appearance of the component, for instance hide some parts of it or add a small bit of logic? You'd add boolean flags and change the component implementation logic to accommodate for them. That's fine while there aren't that many flags - most components never reach that point, so that's ok. But particularly design system components are often used in multiple different ways with slight tweaks for each use case. In that case changing the implementation of the component becomes risky and cumbersome, also the component's implementation logic would grow to support all those different use cases and the prop list would be mostly a bunch of boolean flags. Just passing in an object doesn't help in that case, because it doesn't change the need for those flags and in many cases design system components won't even be using a domain model (the object), but rather generic props to retain flexibility. In that case, composable components are superior. If you want to use the context and compound components - that's your decision, in many cases it would be over-engineering, but in some, they're a nice way to group components together.
This video is amazing. I learned so much from this!! Keep making content like this
gražiai padarytas video. Užprenumeruosiu, reikia palaikyt :D. Nors pats React nelabai naudoju, bet principai visur panašūs, tai vis tiek naudinga.
Thanks so much, never leave comments but this is such a good tutorial 🔥🔥🔥
I literally faced this problem on a project i am working on right now. Thank you!
How about performance when many compound components are defined?
you content is perfect to level up. i hope you dont stop
What are the memory and performance implication for using so many context though if we are replicating it multiple times?
I can only like this video once unfortunately... Really brilliant explanation and example, well done :)
Great video, Vincas. Thank you.
Bro, what a great content, keep it up, that's very helpful. I'm already writing a tweet to share it! Thank you!!
Man I was Just Thinking about the Same Problem for Scalable Components" and The RUclips Recommended it to me. I am Happy now😊😊
I didn't quite understand what are the benefit of passing the image, info and action components vs adding them inside the ProductCard once you've already implemented the context. Wouldn't it be simpler? you'll just have to pass the product as prop and the components inside the ProductCard would get that through the context.
The "slots" is a way to delegate the layout/design decisions to the user of the ProductCard. Without them you'd have no way to make certain parts invisible, reorder them or extend the component easily (without changing the implementation). Basically, this improves flexibility by making the component composable, and the context is just a bit of sugar on top, to reduce the amount of props that need to be passed around.
@@codevincas The props does not delegate those decisions to the user but to the ProductCard itself-you exactly need to change the implementation of ProductCard because it takes those props.
What Prizel is saying is that you could make ProductCard component itself take those compounds as children, since it already provides the context for those components to consume, then pass the product as a prop to the ProductCard. You'd now have even more flexibility over the layout.
Even better, you could use the Radix UI Slot component to further allow other types of user-defined components that will merge its props into the immediate child component. This is a, arguably, better way of handling custom components instead of dealing with `as`/`component` props that otherwise are hard to create types for.
Thank you for making this video. I like how you explain this concept. It's easy to understand.
Very good and thorough step by step.
I really enjoyed it. Keep it up 👍
would it also make sense to put the subcomponents as default values for the Product props and allow them to be nullable, so you would get a default Product which is used most often and you don't have to compose it every time, but you still retain all of the flexibility when you need to have special cases
There's nothing stopping you from doing that, though I would probably create wrapper components for different use cases instead, and leave the composable components as a lower level API.
@@codevincas that makes sense, loved this content btw, cant wait to see more from you
A very good and informative video Vincas, thanks for this 🙇♀🙇
Let's see if I understood correctly the right use cases of this:
I should/could use this whenever I have a component that needs some more details, but those details alone wouldn't be something that I could reuse elsewhere
Seems like this, am I right? :)
That was eyeopening. Thank you!
Sam Selikoff has a great set of videos on implementing RadixUI components which follow a similar design. In fact, once I saw the end result of using the Context API to make the components modular I couldn’t help but think I had seen it somewhere before.
It was a great video and I learned a lot! Subbed 😊
I would like to follow over your video from the initial code.
I'd like to follow along while watching the video, starting from the initial code. Could you possibly provide the initial code too?
Thank you for the video. You can achieve namespacing by perhaps importing everything on a separate file as non default exports if the issue at hand is too many lines of imports. I will personally always favour to as on the latter you're creating a data dependency where the first one you can easily erase Product and will still exist. You could then import everything in one line.
This is a good pattern to use, especially for low level components. prefer slots over props to keep the code of the component easy. Another suggestion i would give is to make the components do as little as possible, whatever you are not sure is not going to be reused most of the times should stay in the parent, i think a common mistake is to pass the options props to a Select component, but the options may be in many format, value-label, value-label-andLotOfOtherStuff, maybe you don't even need the label because you are showing a bunch of icons, also the options may come from an API or may be filterable, and the filtering logic may vary, etc. So just move the handling of the options and the selection of the value in the parent and it will simplify the code of the Select greatly, while the code in the parent would be easy to understand because it will be very specific for that Select.
Great Content!!! Keep doing this!
Thanks!
but wont it affect performance when we map 10 to 100 cards, creating so many context in the back?
Considering info & action prop as childrens would make this more clean and easy to understand
love this video. i learnt soemthing new and had to come back to it just to see what i missed.
Hey,, excellent video! Just a quick question. Let's imagine that you have to render 100 ProductCards. In that case, would you create 100 Context for each card? Thanks!
This is a great video!
Subscribed!
I myself, prefer to develop components so they're easier to use consumer side, I feel like providing variations of a component as a prop is much easier, pass through an Id for the product, and have all logic relating to fetching and deciding layout to the component, learning curve for other developers is much nicer, and you're using the same composition in every place, it makes it much harder to fix bugs or make changes, where if it's inside the component, maintenance is much easier, you end up having to create wrapper components too many times with composition too so that things are reusable
This is a very precious video! Thanks a lot!
Excellent Tutorial.
Very good content! As some people already pointed below, you need to work on the editing. I know it is hard, but this type of things helps to understand better your content.
Absolutely agreed, I'm trying to get better with every video. Do you have suggestions in mind for what I should work on?
@@codevincas I noticed one black screen during the video (4:56). The rest is already pointed by @the stunning iitian.
@@Mong3 Indeed, good point, I totally missed the blank section, sorry about that 😅
This is great, never thought of doing it this way.
That's an amazing explanation for me, thanks a lot!.
This is such a fun and informative video. Love it!
Dood! This is fantastic, I just did something like this and I wish I had seen this first, because you made it easy
Thanks, I'm glad it was helpful!
Dam I learned a lot from this tutorial keep them comming
The idea is great but in nextjs 14 you can only use this component in the client side not on server side.
Can anyone explain why?
React hooks can only be used in client side only. like useContext
Hi! Excelent video, but I have a question, React recommends to use Component Composition every time it's possible and avoid (as much as you can) the use of ContextAPI (Re rendering problems). Will you use Context in a real app in the way you are showing right now? Thanks.
Super nice, thank you for this! By the way, any way to do this with React Server Components without having to use ‘use client’?
there are quite a few draw backs from using this. But for some cases this is quite useful.
Could you provide some of the draw backs please?
@@xacxdcx for starters it’s got no lateral reusability
Bro you saved my ass trying to bootstrap a reusable pattern for my library 🙏🏿 thank you
Great content 👍 the stackblitz link from the description is not working
Huh, it works well for me, but I notice that StackBlitz is not booting up the demo on Mobile and Incognito mode - maybe that's what's happening for you?
@@codevincas it seems to be working now, not sure why it was not loading earlier, thanks for checking it!
That was awesome. Thanks!
Great one mate 🙌
Great Tutorial, Thanks for sharing this awesome tutorial.
One of the best 👌
So like svelte?
you are the best one explain compound component
You did great, a lot of good knowledge from you. Thank u so much.
I wish I saw your video earlier. I just had a live coding interview and had no idea about this principle...
This is the way to go, sadly jr developers still have issues understanding how context work.
We will get there tough ( :
Exactly what i'm looking for. Thank you 👍
great explaination, loved it
Thanks, I appreciate the kind words!
So this is svelte slots in react? Pretty cool
great video !!
Hey Vincas, can you add the initial code in a repo and share it here, It will benefit some of us who want to follow and code alongside.
Wow, amazing.
great video with great quality . I love it .
Thank you! 🙏
Wow. Very helpful.
Question, wouldn't it be better to pass the Compound Components as children? In this use case, it would require one new Component, ProductCardBottom, to wrap info and action sections.
You absolutely can, in fact I would strive to do it this way if you can. It's not always simpler or possible to do it this way though, especially for non-design system components (when they need this kind of flexibility).
Loved this video♥. Instant Subscribe
thank you for sharing!
Imagine having this dude with his keyboard in your office
Great video, but for me it's missing how to do unit test with those components
I am not a fan of monkey patching the main component to include others as subcomponents. Do you know if another way of doing the same thing?
you can use Object.assign(NamespaceComponent, { Child1, Child2 })
This actually is opposite of monkey patching, because you don't need to touch implementation of ProductCard to extend it. If the sub-components are bothering you, you can always create a wrapper with props - just like in the beginning. That's the flexibility composition gives you!
Thank's for the answer. What I mean is I do not want to mutate the object ProductCard, not its implementation. Since the patch is done in a separate file, there is now way of knowing where ProductCard.x comes from (except with folder structure and naming conventions, but that is not enough of a guarantee for me). I was wondering what would the best way of extending the ProductCard object in the same way, but from the root file, so that all the existing subcomponents are visible when reading the main component file.
Also, does the linter manage that stuff well?
Something like function Product() {
this.Image = ProductImage
}
Although it might mess with rendering
ReactNOde 3 times in a row, bingo!
got to know something new ,thanks a lot
Awesome video, keep it up 👍
why did you stop making videos?
Nice video! Quick suggestions:
1. Add ambient music in the background to make it more immersive while watching
2. Make the video more about the topic and example code by having snippets ready to paste than typing manually
3. Could work on some tone modulations while explaining i.e varying intensity, some animations, etc.
Watch Hyperplexed on YT as he grew very quickly due to loopable content. Good luck!
Thanks for the comment, I might add BGM in the next video and I do need to work on the smoothness of my talking, but it will come with practice I hope. I'm experimenting with different ways to present code atm, will try to do some copy-pasting in some sections for longer videos, or edit out the typing part. Hyperplexed is next level stuff, he's not doing long-form tutorials, but is definitely inspiring though.
1. I'm actually quite happy there's not background music. If I wanted any, I'd play my own 😅
2. As the typing has roughly the same duration as the explanations... I think they match well.
No BGM necessary. It's a distraction that will compete with his voice, which is the most important element of a tutorial video.
Hard disagree. I don't want ambient music.
I liked the typing
awesome tutorial. Keep em comig
Holly shit this is nice! Thanks for sharing!
very good video, you opened eyes :D Got a sub