18:07 این نیز بگذرد. 😊 You are absolutely one of the best react UA-camer I've ever known. Instead of just focusing on tooling and trends, you have shown us real way to become a senior react developer. And for some reasons I feel very proud 😉
This is extremily powerfull but, as he mention, DON'T USE IT anywhere or even worst, DON'T USE IT if u don't know what ure doing ... 6+ years of React here and toke me around 4 days to play with this methodology and understand the real need for it. It's beautiful but, requeries UX/UI experience and React maturity. Best channel by far and keep this insane work bro, ever for seniors like me, u still save us a lot a doubts here and there, 😂 🤘 cheers!!!
@@isaacjon Shure, everything is relative and depends and salary's for a more senior role can start around 4K USD/month and flyes higher, again, very depends... Keep one thing in mind, seniority's is much more about maturity and exp than code itself alright? I have 15+ in development/design specialized in frontend so, u will never know every syntax or 100% of something but, if u have the business mind and understatement on how a software works and it's layers and business flow, you will be ahead of millions. Struggle? Linkedin recruiters reach me at least 2 times per week offering something so, if u have maturity + exp + prove in a interview what u are capable of, u more than fine to proceed and keep trying but, keep in mind that, is annoying get hired cause u will fight for the role with a lot of people. It doesn't mean that u no good enough, it's just the reality of life, everything happens in gods time, not ours, cheers bro I hope it helps! 🤘
@@isaacjon "Hey, I wrote you a reply, but I think the UA-cam algorithm didn't like it. So here's another one. I'm not talking about money because this is highly relative to the role and your level. One thing I can say for sure is that development is much more about maturity and experience rather than just technical knowledge. You must understand very well how the layers of a software work in order to develop a sense and experience inside you where you just know stuff, and even when you don't, you have an idea of what you have to do in different scenarios." I hope it helps, cheers! 🤘
@@hakanberat Sure bro, it's very simple and u will never forget... Use Case for CC: Employ compound components when you need a versatile UI element that is used repeatedly across your app but requires adaptability based on the context or data it receives. For example, a notification component that needs to conform to a UI design pattern while also varying in presentation-such as with or without buttons, icons, or read status-based on different scenarios. When Not to Use: Avoid using compound components for static UI elements that do not vary and are used consistently throughout the app, such as a navigation top bar. These elements do not benefit from the adaptability that compound components provide. Note on Figma and Frontend: It's important to distinguish between component usage in Figma and frontend development. In Figma, designing various scenarios for a component is common, but not every design needs to be implemented as a compound component in the frontend. The decision should be based on the specific needs and rules of your project. I hope this streamlined explanation is helpful! 🤘
The time you take to explain the design process really pays off in your videos, especially here. We appreciate it! Such a cool and useful way of using context
One Year or watching your Design pattern video could transform one into a senior react developer, if you can do two desing pattern videos in a week I would be in love lol
I literally came across a perfect use case for this at my job some days ago, but ended up using render props instead I knew about this design pattern from shadcn components but I didn’t really know what to look for to learn more and implement it. Thank you so much for this!
Your videos is HIGH QUALITY and just absolutely SIMPLE TO UNDERSTAND !!!! Just amazing bro. Kindly keep with this style of teaching and don't change !! And thank you. For teaching me complex topics in such an easy to understand way and using examples. May the CODE be with you 🙌
Awesome work! Keep in mind that compound components syntactically cannot be used in an RSC, eg: // will not work -> error Therefore PostTitle must be exported individually in order to be imported like this: // will work -> no error
Very nice video! I've been working with React for a long time, and when I see that pattern, it opens up a lot of possibilities in my React projects. Thanks from Brazil!
This is by far the best explanation of compound components I've seen so far. I wanted to learn it since a while ago but all resources that I read or watched were too complicated for me to understand. Great work! BTW, can you please create a few videos to show how testing is done in React? I'm referring to complex use cases where you'd need to test custom hooks, contexts, or hooks which fetch data so you have to mock API for them.
I use the same pattern, but instead of passing all props to PostCard, i use the "subcomponents" rendering childrens too, like Hello, World, because you can do more things with your component, like if you need to change the color of the title or adding an icon after the text, things like this. Anyway, excellent video! :)
Yep, this is the way you should use this pattern as it gives you a tonne more flexibility. It also removes the need for context just to share data around and makes handling events a bit easier. That isn't to say context isn't useful, but you can then use it for sending non-data props on the top component to the children which is a bit tidier. For instance, you could have a `size` prop on which changes the styling, and then make it so things like and use this to look appropriate. Ie, to handle the appearance and any logic inherent to that component. Essentially it changes these components to be purely about *how* to display the post elements, not what parts of the post to display.
You know, I'm not a React developer, actually I work with Vue but I always watch your videos because it gives me some valuable insights that I apply for Vue hahaha Another great video!
I’m fan of the compound components because they give you more flexibility in different scenarios. I’m not completely sold on passing post as a prop and sharing with the others via context. In my opinion instead of passing post as a prop and getting the child components to render the title and instead just get them to render children. This way the consumer will have more control and no need to use context.
I had a similar thought too. For simpler compound components I could see the provider working well but more complex ones with subcomponents handling many props the render children would be better
@@jasonvictor1798 The problem is that in a lot of projects, simple components eventually become complex ones with scope creep. So doing this exact style for them is just inviting code issues in the future.
Great idea! Thanks for the tutorial on this. I'm definitely guilty of adding a quick boolean prop to change some things around every now and then lol. 1 unrelated question though, any reason you're using types instead of interfaces? Are there any drawbacks? I've usually used types just for quick string types like: type Status = 'open' | 'cancelled' | 'complete'; Great content though, i wasn't subscribed before but i am now! Thanks man!
Another Great video!! Thanks for this, but I would like to know from where do you get these information? Like where did you come across Compound Components is a Design Pattern in react?
nowhere specific, but heard about it from multiple places online over the years, and eventually started to use it and really liked it for specific use cases
Thank you for all these amazing videos, I wonder how can I effectively use the react dev tool profiler. I struggling making sense of it. Thank you again.
Hey man, great video! I have a question though when using Nextjs. I get a bundler error when using compound components like this - when used within my page.js I must declare 'use client' if the compound component file is also 'use client' - which is not the case, server components can have client components. Not a big deal, but have you experienced the same? And I hope they can find a way to fix this - likely due to compound component pieces not being default exported, yeah?
I have a question if we use nextjs, usecontext when the place we use, we have to make it as a client component how to get rid of them because most of the time the data fetch from a db so it a server component
It works well on dull component, but what if you at least had buttons with handlers ? What if you have more than 2 possible actions ? context will be enormously big.
Typically you don't really do it exactly like this. Instead you might have something more like CancelSave. The idea being that you let higher level component determine the interactive elements, keeping the control (and responsibility) on that layer. Take a look at things like @shadcn/ui and other component libraries to see how this pattern is meant to be used. In the version shown in this video, it has issues where you can't modify easily the layout of the posts, since you're just determining the elements to display rather than anything else. Not entirely bad, it depends on the project. However, the more typical usage is to not use context at all, but instead the parent element puts the post data in itself: {post.title} {post.description} by {post.author} The advantages here is that the parent element is relatively unconcerned about how the post is rendered, but has full control of what is rendered. For instance, if it's for previewing the post, it could just use {post.description.substring(0, 50)}... to show only the first 50 characters of the post. Of course, you trade in more complexity and responsibility in the parent component. It's always swings and roundabouts!
Aren't this gonna make all the components client components, since they are using context to get the post data? If you instead of using context, just parsed the post as props to the new components, this would get rid of having them all becone client components - right? But I like the general take on this
Hello cosden , do you trust me , i was trying to do something like this , this morning Thank you my freind For next video , maybe Framer motion or some popular web motions using framer motion I don't know if i don,t have creativity or isf-motion hard to me ! 😅
One example that comes to my mind is pagination component as it have many variants bases on location its used: - with previous next button and numbers - with just numbers - with dots only - with dots + any thoughts?
That's such a cool solution! However, let's say I'm on the same page and I want to render the same component x times. The component is rendered using the map() method because it fetches data. For exemple I need my component to display titles for the first two instances, but not for the third. How would you approach this using compound components ?
one more thing: it would be rather to have passing rest props of html element and merge classNames to have able to update in from outside. You need care about performance, {{ spot }} - will update context value and re-render every component that use it and with post prop in parent same. I thing you did't have purpose to focus on it. Just a lot of people don't really understand how they make them apps slow after look videos. I had such people on my work and they as proof used arguments - look, on this video this guy don't use memoization and smt like that))
@@PeterSahanaya react 19 dont give you nothing for solve this, it will do react compiler :) and still you need to understand how it works and how write code correctly) but yes, most of that wont be necessary
Dude i love your content but can you tell me in this code you are passing entire post into every sub components.does this is not violating the design pattern?
Hello Cosden, This is a nice video you have here. Compound Components are great patterns for ReactJS But, i feel you used ReactJS context as an overkill here. For example, PostCard.Buttons, what of i want to change the button text or i want one button that is centered in the card instead of two buttons ? See... We are right back to using those meaningless boolean props that only affect visibility of a DOM/JSX element. Compound Components work better when they start out completely headless. Also, was the use of ReactJS context absolutely necessary? I think not. It's too much overhead as useContext should mostly be use to share data across a wide area of a component tree not a small localised area of it. You could have simply used React.Children.map(...) to validate that each of the children of the PostCard component where the other ones which you defined using the `isSubChild` function. export const isSubChild = ( child: React.ReactNode, tag: string ): child is C => React.isValidElement(child) && String(child?.type).includes(tag); See example here (for isSubChild): github.com/isocroft/ReactJS_SPA_Starter-pack_plus_UI_Components/blob/main/src/components/UI_Widgets/Tabs/index.tsx Finally, naming matters in terms of the hierarchy of the UI components in a design system. i.e. Start with Card -> then, -> PostCard The design system must have a hierarchy process from subatoms -> atoms -> molecules -> organisms subatoms and atoms MUST be completely headless, while molecules can have stlying but very basic (without colors, backgrounds, box-shadows and rounded corners). Then organims can now have full styling with colors, box-shadows and all.
Nice one but I wouldn't use Context unless it's necessary. In the video example I don't think it is, I would just pass children with the content I want instead of having to access to the properties from Context.
Generally prefer this pattern to avoid needing to keep adjusting components to expose additional options when requirements change. However, I usually prefer to just provide the relevant props to the inner components instead of using a context provider. This also allows you to use RSC instead of client components for these components
In NextJS I would not recommend using context, unless your sub-components interact with each other, so you can take advantage of server components for example, the title subcomponent you can ada the content as children like so {post.title}
+1, context is not necessary at all if you just put children props in every sup components, it retains the deaign pattern and matches at the same time your component is also rendered in server
I don't really like this design pattern, you pass all the data (post) to the PostCard, but not always all the data needs to be used - depending on the use of the subcomponents. In addition, if I want to use such a component in several places, I have to list subcomponents everywhere - if I want to avoid this, I can create a packaging component, but I find it undesirable, while it would be enough to create a component, for example SimplePostCard, where I pass only the necessary data, which component actually needs and I will meet its interface.
I've seen tutorials on this topic before, but this one does a way better job explaining on why to use the context. Thank you!
Literally what I was looking for. I had a component that needed to pass bunch of booleans and stuff for each case. Now, I know what to do!
I've been hearing about the compound component for over a year. You've clarified it now. All the examples talked about select. Thanks
18:07 این نیز بگذرد. 😊
You are absolutely one of the best react UA-camer I've ever known.
Instead of just focusing on tooling and trends, you have shown us real way to become a senior react developer.
And for some reasons I feel very proud 😉
This is extremily powerfull but, as he mention, DON'T USE IT anywhere or even worst, DON'T USE IT if u don't know what ure doing ... 6+ years of React here and toke me around 4 days to play with this methodology and understand the real need for it. It's beautiful but, requeries UX/UI experience and React maturity. Best channel by far and keep this insane work bro, ever for seniors like me, u still save us a lot a doubts here and there, 😂 🤘 cheers!!!
Is it possible to let us know what is your salary as a react developer with 6+ experience? Do you struggle to find a job or not in these days?
@@isaacjon Shure, everything is relative and depends and salary's for a more senior role can start around 4K USD/month and flyes higher, again, very depends... Keep one thing in mind, seniority's is much more about maturity and exp than code itself alright? I have 15+ in development/design specialized in frontend so, u will never know every syntax or 100% of something but, if u have the business mind and understatement on how a software works and it's layers and business flow, you will be ahead of millions. Struggle? Linkedin recruiters reach me at least 2 times per week offering something so, if u have maturity + exp + prove in a interview what u are capable of, u more than fine to proceed and keep trying but, keep in mind that, is annoying get hired cause u will fight for the role with a lot of people. It doesn't mean that u no good enough, it's just the reality of life, everything happens in gods time, not ours, cheers bro I hope it helps! 🤘
@@isaacjon "Hey, I wrote you a reply, but I think the UA-cam algorithm didn't like it. So here's another one. I'm not talking about money because this is highly relative to the role and your level. One thing I can say for sure is that development is much more about maturity and experience rather than just technical knowledge. You must understand very well how the layers of a software work in order to develop a sense and experience inside you where you just know stuff, and even when you don't, you have an idea of what you have to do in different scenarios." I hope it helps, cheers! 🤘
Hey @marceloviannadev , can you give examples of usecases where we should not use this pattern?
@@hakanberat Sure bro, it's very simple and u will never forget...
Use Case for CC: Employ compound components when you need a versatile UI element that is used repeatedly across your app but requires adaptability based on the context or data it receives. For example, a notification component that needs to conform to a UI design pattern while also varying in presentation-such as with or without buttons, icons, or read status-based on different scenarios.
When Not to Use: Avoid using compound components for static UI elements that do not vary and are used consistently throughout the app, such as a navigation top bar. These elements do not benefit from the adaptability that compound components provide.
Note on Figma and Frontend: It's important to distinguish between component usage in Figma and frontend development. In Figma, designing various scenarios for a component is common, but not every design needs to be implemented as a compound component in the frontend. The decision should be based on the specific needs and rules of your project.
I hope this streamlined explanation is helpful! 🤘
The time you take to explain the design process really pays off in your videos, especially here. We appreciate it! Such a cool and useful way of using context
As always, you're on a super high level comparing to other teachers/mentors. Thanks for your videos, keep doing that!
One Year or watching your Design pattern video could transform one into a senior react developer, if you can do two desing pattern videos in a week I would be in love lol
Thank you, bun in my opinion, in such cases it may be comfortable to use a wrapper and pass dependent components inside with the corresponding props.
I literally came across a perfect use case for this at my job some days ago, but ended up using render props instead
I knew about this design pattern from shadcn components but I didn’t really know what to look for to learn more and implement it.
Thank you so much for this!
Your videos is HIGH QUALITY and just absolutely SIMPLE TO UNDERSTAND !!!!
Just amazing bro.
Kindly keep with this style of teaching and don't change !!
And thank you.
For teaching me complex topics in such an easy to understand way and using examples.
May the CODE be with you 🙌
thank you for the kind words!
Awesome work!
Keep in mind that compound components syntactically cannot be used in an RSC, eg:
// will not work -> error
Therefore PostTitle must be exported individually in order to be imported like this:
// will work -> no error
f00king rsc’s.
Very nice video! I've been working with React for a long time, and when I see that pattern, it opens up a lot of possibilities in my React projects. Thanks from Brazil!
These design pattern videos are amazing!!! This is by far one of the best channels to learn how to code, everything is very concise and clear 🔥🔥🔥
Great , simple and straightforward explaination as usual
You're really talented in complicated things explanation bro, keep it up! This is my favorite channel about React 👍
This is by far the best explanation of compound components I've seen so far. I wanted to learn it since a while ago but all resources that I read or watched were too complicated for me to understand. Great work! BTW, can you please create a few videos to show how testing is done in React? I'm referring to complex use cases where you'd need to test custom hooks, contexts, or hooks which fetch data so you have to mock API for them.
And it gets even more interesting when the subcomponents modify the main component state to change other subcomponent's behavior!
Awesome content (very rare) , keep up the good work 💙
I use the same pattern, but instead of passing all props to PostCard, i use the "subcomponents" rendering childrens too, like Hello, World, because you can do more things with your component, like if you need to change the color of the title or adding an icon after the text, things like this. Anyway, excellent video! :)
Yes
Yep, this is the way you should use this pattern as it gives you a tonne more flexibility. It also removes the need for context just to share data around and makes handling events a bit easier. That isn't to say context isn't useful, but you can then use it for sending non-data props on the top component to the children which is a bit tidier. For instance, you could have a `size` prop on which changes the styling, and then make it so things like and use this to look appropriate. Ie, to handle the appearance and any logic inherent to that component.
Essentially it changes these components to be purely about *how* to display the post elements, not what parts of the post to display.
You know, I'm not a React developer, actually I work with Vue but I always watch your videos because it gives me some valuable insights that I apply for Vue hahaha Another great video!
This is amazing! Altough i'm kind of confused as to why you would you use context for this instead of just passing the post as a prop.
Thank you, very useful, expect you will refer more react patterns
I’m fan of the compound components because they give you more flexibility in different scenarios. I’m not completely sold on passing post as a prop and sharing with the others via context. In my opinion instead of passing post as a prop and getting the child components to render the title and instead just get them to render children. This way the consumer will have more control and no need to use context.
I had a similar thought too. For simpler compound components I could see the provider working well but more complex ones with subcomponents handling many props the render children would be better
@@jasonvictor1798 The problem is that in a lot of projects, simple components eventually become complex ones with scope creep. So doing this exact style for them is just inviting code issues in the future.
Great idea! Thanks for the tutorial on this. I'm definitely guilty of adding a quick boolean prop to change some things around every now and then lol.
1 unrelated question though, any reason you're using types instead of interfaces? Are there any drawbacks? I've usually used types just for quick string types like:
type Status = 'open' | 'cancelled' | 'complete';
Great content though, i wasn't subscribed before but i am now! Thanks man!
thank you so much for this. your content is really really good. Learning a lot. Thank you 🙌
One om my favourite patterns to build UIs 🔥
Very good video, keep up the good work, we appreciate the good material of patterns and others in react.
This is so lovely, and coming handy! Thank you Cosden!
I would love to see you make a video completing a project from start to finish to see your process and learn from you
that's exactly what is project react :D
@@cosdensolutions Oh. I'm broke as hell unfortunately
Love this kind of videos and the way you explain the step by step process, keep it up!
Really good tutorials, cheers dude!
Compound Components are just too OP
Another Great video!! Thanks for this, but I would like to know from where do you get these information? Like where did you come across Compound Components is a Design Pattern in react?
nowhere specific, but heard about it from multiple places online over the years, and eventually started to use it and really liked it for specific use cases
video starts at 01:07
i always wondered how ui libraries did this, thanks!
Thank you for all these amazing videos, I wonder how can I effectively use the react dev tool profiler. I struggling making sense of it. Thank you again.
OMG this is so cool! I urgently need to apply it somewhere!
Nice video. I subscribed. Is there any other downsides?
Hey man, great video! I have a question though when using Nextjs. I get a bundler error when using compound components like this - when used within my page.js I must declare 'use client' if the compound component file is also 'use client' - which is not the case, server components can have client components. Not a big deal, but have you experienced the same? And I hope they can find a way to fix this - likely due to compound component pieces not being default exported, yeah?
Excelent video as usual! This pattern is similar to the Composition Pattern, which is also quite interesting. Thanks =)
I have a question if we use nextjs, usecontext when the place we use, we have to make it as a client component how to get rid of them because most of the time the data fetch from a db so it a server component
It works well on dull component, but what if you at least had buttons with handlers ? What if you have more than 2 possible actions ? context will be enormously big.
Typically you don't really do it exactly like this. Instead you might have something more like CancelSave. The idea being that you let higher level component determine the interactive elements, keeping the control (and responsibility) on that layer.
Take a look at things like @shadcn/ui and other component libraries to see how this pattern is meant to be used.
In the version shown in this video, it has issues where you can't modify easily the layout of the posts, since you're just determining the elements to display rather than anything else. Not entirely bad, it depends on the project. However, the more typical usage is to not use context at all, but instead the parent element puts the post data in itself:
{post.title}
{post.description}
by {post.author}
The advantages here is that the parent element is relatively unconcerned about how the post is rendered, but has full control of what is rendered. For instance, if it's for previewing the post, it could just use {post.description.substring(0, 50)}... to show only the first 50 characters of the post. Of course, you trade in more complexity and responsibility in the parent component. It's always swings and roundabouts!
I hope you do Next.js videos as well
great vid man. got a new subscriber
Aren't this gonna make all the components client components, since they are using context to get the post data? If you instead of using context, just parsed the post as props to the new components, this would get rid of having them all becone client components - right? But I like the general take on this
or just passing the content as children, for ex: {post.content}
Top tier contents! 👍
ahaha, I finally know how this is called :D Thanks, great vids, do more of them pls!
It was very helpful. Thanks.
Love it. Great explanation. Thanks.
Dammmm, you are my react Hero ❤
great! however, i believe to keep consistence, you'd better not use this pattern unless it's really necessary.
Hello cosden , do you trust me , i was trying to do something like this , this morning
Thank you my freind
For next video , maybe Framer motion or some popular web motions using framer motion
I don't know if i don,t have creativity or isf-motion hard to me ! 😅
please create a video about rtk query as well
More pls on this topic
One example that comes to my mind is pagination component as it have many variants bases on location its used:
- with previous next button and numbers
- with just numbers
- with dots only
- with dots +
any thoughts?
make more videos like this !!!
Great Tuto!!! Thank you!!
That's such a cool solution!
However, let's say I'm on the same page and I want to render the same component x times.
The component is rendered using the map() method because it fetches data.
For exemple I need my component to display titles for the first two instances, but not for the third.
How would you approach this using compound components ?
Just use the same pattern, and use the index to conditionally render the component.Title
one more thing: it would be rather to have passing rest props of html element and merge classNames to have able to update in from outside.
You need care about performance, {{ spot }} - will update context value and re-render every component that use it and with post prop in parent same. I thing you did't have purpose to focus on it. Just a lot of people don't really understand how they make them apps slow after look videos. I had such people on my work and they as proof used arguments - look, on this video this guy don't use memoization and smt like that))
react 19 be like : Are sure about that broda?
@@PeterSahanaya react 19 dont give you nothing for solve this, it will do react compiler :) and still you need to understand how it works and how write code correctly) but yes, most of that wont be necessary
@@snatvb yeaa, you're right, we still need to know what happen under the hood
I have a question related to React.memo. If I use React.memo for the PostCard component, will it affect compound components?
Amazing video! Thank you so much
Useful content! Thank you bro
Dude i love your content but can you tell me in this code you are passing entire post into every sub components.does this is not violating the design pattern?
I love this tutorial🔥.
Love this!!! Thanks for this usefull info
5:46 How do you remove entire lines and selected text so quickly?
Vim
Love your videos, very informing
this would mean that the post component can no longer be a server component and has to be a client component?
…awesome Cos 👌🏾
this is dope
Hello Cosden,
This is a nice video you have here. Compound Components are great patterns for ReactJS
But, i feel you used ReactJS context as an overkill here.
For example, PostCard.Buttons, what of i want to change the button text or i want one button that is centered in the card instead of two buttons ? See... We are right back to using those meaningless boolean props that only affect visibility of a DOM/JSX element.
Compound Components work better when they start out completely headless.
Also, was the use of ReactJS context absolutely necessary? I think not. It's too much overhead as useContext should mostly be use to share data across a wide area of a component tree not a small localised area of it. You could have simply used React.Children.map(...) to validate that each of the children of the PostCard component where the other ones which you defined using the `isSubChild` function.
export const isSubChild = (
child: React.ReactNode,
tag: string
): child is C =>
React.isValidElement(child) && String(child?.type).includes(tag);
See example here (for isSubChild): github.com/isocroft/ReactJS_SPA_Starter-pack_plus_UI_Components/blob/main/src/components/UI_Widgets/Tabs/index.tsx
Finally, naming matters in terms of the hierarchy of the UI components in a design system. i.e. Start with Card -> then, -> PostCard
The design system must have a hierarchy process from subatoms -> atoms -> molecules -> organisms
subatoms and atoms MUST be completely headless, while molecules can have stlying but very basic (without colors, backgrounds, box-shadows and rounded corners).
Then organims can now have full styling with colors, box-shadows and all.
It was really useful
sorry i'm new, while learning i would use interface but now i'm seeing type is it the same ? If not what's the difference?
Interface is used for mainly declaring types for objects... And type is used for both
E.g, types me= string, me interface{
Me: string
}
Thank you
thanks!
Extremely powerful 👍
This looks good ❤
Nice one but I wouldn't use Context unless it's necessary. In the video example I don't think it is, I would just pass children with the content I want instead of having to access to the properties from Context.
amazing video
"این نیز بگذرد"
This too shall pass
That's amazing 🔥
Thank you ❤
it's amazing.
How i can get Source code?
thanks
sir do you upload your courses in udemy?
awesome
this is awesome
Why not to use Factory Pattern to create different Card components from a base Card component it would be easier and cleaner IMHO?
Generally prefer this pattern to avoid needing to keep adjusting components to expose additional options when requirements change.
However, I usually prefer to just provide the relevant props to the inner components instead of using a context provider. This also allows you to use RSC instead of client components for these components
It's crucial to think about how the component will manage various data types and adapt to dynamic content.
In NextJS I would not recommend using context, unless your sub-components interact with each other, so you can take advantage of server components
for example, the title subcomponent you can ada the content as children like so {post.title}
yeah that's a very good point!
True, don't need a context at all.
+1, context is not necessary at all if you just put children props in every sup components, it retains the deaign pattern and matches at the same time your component is also rendered in server
But then how would you stop the component being rendered outside it's parent component without the having the context hook throwing an error?
@@cosdensolutions it's good for abstraction have not a context but how to prevent use of subComps outside?
Can this be used in react native
Yes
This approach is used by chadcn components
bro i want to buy your cource but its too expensive for india
Wow exceelent
how its different then just creating atomic components and building them at call site . you just have use context to reduce params, rest code is same.
I don't really like this design pattern, you pass all the data (post) to the PostCard, but not always all the data needs to be used - depending on the use of the subcomponents. In addition, if I want to use such a component in several places, I have to list subcomponents everywhere - if I want to avoid this, I can create a packaging component, but I find it undesirable, while it would be enough to create a component, for example SimplePostCard, where I pass only the necessary data, which component actually needs and I will meet its interface.
I've to be honest.. I've been working with for more than 3 years and I have never use comp. Compns😞