Hope you enjoyed the video! I also have a really cool and unique course that will teach you way more than this video. You'll learn how to build an actual complex project with React. It's called "Project React" and you can find it at cosden.solutions/project-react. Also, I have a free weekly newsletter called "Import React" with tutorials, news, and cool stuff about React! You can sign up at cosden.solutions/newsletter?s=ytc
Love your videos man. Find them very helpful. I’m an experienced backend developer, finally biting the bullet and reaching myself react (if that’s at all helpful info). Making my way through every videos you’ve made lol
Hi, Don't you think that HomePage violates the Single responsibilities principle? Because the HomePage component fetches posts, in the future it may be responsible for sorting posts, etc. + it renders content in the future HomePage also can render something else, which may also require fetching data. Isn’t it better to move the state and fetch to the PostFeed component and fetch the posts there? In this case PostFeed will be responsible for posts logic. If we want PostFeed to be reusable, we can rename this component to just Posts (will accept posts as props) and create a wrapper e.g HomePagePosts which will have a posts state and fetch the data and pass this data to the Posts component through the props? What do you think?
Great question! So first, I don't think it violates it at all. Any React component needs to return something, so that by default makes it responsible for what it returns. In most cases, that's JSX so it's responsible for returning that and providing everything those components need. What I meant with the single responsibility principle, is that each component should have only one obvious job. In the HomePage, that job is to hold the state needed to render itself. So that means holding and fetching the posts, or if there's sorting implemented then holding the function that sorts the posts and passes it to the component that sorts, and anything else that it needs for its own content. The single responsibility here is: render the HomePage. Everything else it should delegate to other components. So you could've fetched the posts in the PostFeed component sure, but then the HomePage would've needed to hold some object with params to fetch with. So then that would become its responsibility. If you had a ProfilePage, it would hold different params such as the userId to fetch only those posts. That would be its responsibility. Then you can have other components, like the PostCard which is only responsible for rendering a single post. But that may mean it can hold some state, or fetch some data that it needs to render the post, or even filter stuff there. It still falls under the responsibility of: render a Post. That's the key, it's not about actually doing one single thing, but being responsible for one thing and holding all the code necessary for that one thing, even if that means multiple states and effects and props passed to other components!
what you could also do is extract all posts fetching logic in a custom hook (usePosts) - as explained in the last design pattern in the video. In this hook, you can move the fetching part that is present in the HomePage. Imagine having filters, sorts, different views options (as cards, as list, etc). The HomePage would have lots of logic in it + testing would be a nightmare and not possible to do unit testing correctly -> you would render a giant component every time you want to test isolated capabilities: filters, sorts, etc
Don't you hate when you know that there is a better way to do something, but you don't know the right terms to search for? I needed a compound component on a recent project but ended up coding my way around it. Thanks for these videos, when developers can talk to humans it's their responsibility to help. I was a tutor for a few years. I bet making these videos has helped you develop even better.
I totally know what you mean! Many times have I searched for something but didn't know the specific words. For what it's worth, AI helps with that a lot. You can try describing your thing and it might give you the right answer
@@cosdensolutions I just signed up for co pilot but I’m not in the habit of leaning on that yet. The video sponsor looks like a cool way of setting stuff like that up too. If they integrate storybook into that it will be a power house.
I absolutely relate to that. ChatGPT is a great help as it feels like you're talking to a real mentor. Unlike asking in StackOverflow whose egotistical users will either flag your question as duplicate even if it's not or mock/make fun of whoever is asking. Then there are those articles that most of the times don't help at all. The experience is vastly different than using a search engine.
The only thing I would say about having your fetching and state in your parent component is that when you update that data, your whole page will reload, not just the componants using the data.
Hi, I wonder about the last pattern 'extract useEffect to other files', if we have too many dependencies related to useEffect such as the variables from useState for checking, how can we handle that?
@Cosden Solutions - 2:10 You are not supposed to use side effects directly like this in React components. You should make a custom hooks / utility functions to adhere dependency inversion principle and separation of concerns principle...
It also creates questions on what is the source of truth for posts? What if the posts on the server updates and we want to display those to the user? Also during that first render - even if the api calls are cached - it will have posts being null. This is a massive anti-pattern for so many reasons!
I am wondering about useSelecContext hook in 10:39. Why do you use useContext in a single component. It this used somewhere else in code except that select component that is shown on video? What it used it for? Maybe for taking the value in a parent komponent or what?
Hello sir, could you please bring a series on advance senior developer code for instance an open source react project code like a ui library. How they code, what should be the correct way to make a feature and so on. BTW love your content
Hey Cosden, thanks a lot for sharing your knowledge with us. Which monitor do you use for your mac? I have been struggling to find a decent one with crisp text for my mac mini :(
SRP is a good pattern but can lead to the following drawbacks: excessive fragmentation, increased boilerplate code, decreased readability, difficulty in debugging, and an increased onboarding time for developers. For small and even some medium-sized projects, sometimes it's just simpler and easier to AVOID breaking things down into multiple responsibilities and files. Sometimes it IS more readable if it's in a single place.
I currently don't do 1v1 (but that might change in the future). However, I am soon launching a course that takes everything I've learnt over my career and puts it into a package that goes significantly beyond what my videos do. It's coming in a month and a bit!
Great video! However, there is something that is bothering me. Why should we reinvent the Select behavior when it's already implemented by the browser? But the pattern is awesome and should be utilized.
Generally it's good to have your own components that wrap the browser elements just so you can add any customisations you need there and have them apply to all of your app, instead of repeating it every time you use a select input. You can style them, add additional props, etc all in one place to re-use
Never seen or used compound component pattern before. Very interesting. I'm curious in what other real world scenarios it would be beneficial to use. Thanks!
Thanks for the Video , but i see an issue with Props Drilling! we are passing the posts to 3 child components! can you explain why this is a bette practice than creating a posts context ?
posts is only passed to PostFeed. PostFeed then maps over the posts and passes a post to PostCard. This is not prop drilling, this is just normal React! A context wouldn't make sense here!
That was a really interesting video! Thanks for sharing. A question about extracting logic into Hooks - how do you share state from the hooks back into the component itself? Would you return a big object full of properties similar to how useState works?
the thing that I would personally do is just returning the properties that i need. For instance, if i fetch some data and put it in the state, i'll then just return the value from the state without anything else (apart from common utils like isLoading, error etc...), in order to let the component consume only the things that it actually needs
Yes you return everything that you need! Usually in the form of an object with the properties inside so that you then use them with the same name in the component!
I wouldn't, because you would also use PostFeed in the UserProfilePage for example, where you'd need to fetch all posts of a specific user. So you would need to pass some sort of filters from the HomePage and UserProfilePage. So at that point, just fetch them there and let PostFeed display them only
@@cosdensolutions Passing the filters seems fine imo // Home. // Profile. Or similar. But to each their own, and hard to say without a larger app context. Cheers, love the vids.
It also creates performance issues, especially when we want the user to poll the server occasionally to get the latest data. If HomePage has multiple components which might all require their own data obtained from API calls which are all placed in HomePage, then when any of these updates, all of the components will re-render. Not a problem in toy projects but can be a major one in larger ones. PostFeed with potential filter props, and then using something like React Query makes a tonne more sense, and would be much more performant. Again, in larger projects, it would make it much easier to look at the logic since it's colocated with the appropriate component. The main con against this is creating the need to the mock RQ or your fetching API/hook when testing your component instead of simply sending it an array of Post objects. However, that's not particularly difficult to do.
I've started working for my first time at a company at a level of junior. I've already extracted a topic dashboard page into multiple hooks for easier management. I was required to hooks which was used in another hooks,, is this a good idea?
The Select context option feels unnesarily complex. Custom hooks + useContext for a native form element? You mention that it's nice because now it's a simple and reusable component, but you've created something that is finicky, difficult to understand and hard to maintain. That's the opposite of a senior design pattern.
The SRP is arguable here, for this example, homepage component should not be responsible for fetching posts, that's a responsibility for Posts component to do, imagine that homepage has other components that need some data from an API, so the homepage component will be a mess, therefore, we'll be violating SRP. Also the last patten is arguable indeed, if we do that for every component, then we're losing colocation principle which I think it's more meaningful than just move things around, instead I think smart/dump components pattern would make much sense in such situation instead of using custom hooks. Thanks for the video though
Great work I really learned a lot! One question for minute 14:00 would you also make a sepearte file Component.helpers.ts for functions like const handleSubmit e => {} and other functions? Also how would you do it on server components where you can't use hooks?
Can you do a video about select.option. Watched it 10 time in speed 0.75.. I don´t get it. I get why it need to be in a select. But I don´t get the Select.option tag
Really love theses kind of videos! Thank you! One question, and sorry if it would be obvious, but I really liked the last pattern, bit how would it be implemented if I need a control state? Or that would be more like the second pattern shown?
I'm not sure what you mean by control state, but extracting that in a custom ".hooks" file is no different than having that code directly in the component. So you could have that custom hook receive props from the component or from above, and even return a value too. This will work exactly in the same way, with the only difference being that now everything runs through and from this extra file
@@cosdensolutions sorry, sometimes I'm not so clear in english :( What I meant is if I need that state that (also) controls something outside of that .hooks file. Although I might be looking wrongly at the problem x solution. ~ just to make an excuse ~ Been a couple months I'm not coding, kinda discouraged, so maybe that's why I'm not looking at this properly.
@@danieldk5148 in that case, you need to pass the callback function to update that state through props to this component, and then pass it to the hook in .hooks. Then call it in there and it will update wherever the source is!
Great Content! But I see an issue in the video, you said "Single Responsibility Principle" as a pattern, which I think is not true." Single Responsibility Principle" is not a pattern. It is one of the principle belongs to SOLID principles. If I'm wrong. Do clarify this thing kindly.
Hello sir, please make a video on feature driven folder structure a.k.a screaming architecture - no youtuber has covered this till now and i am expecting from you .....
and i would like to know how to give answer please explain about your fronted project architecture ? give your sample react project architecture example .!
SRP is not a design pattern but a SOLID principle. And the first ex is not quite good. should only return JSX (view layer) should only return JSX (view layer) should fetch data (model layer) P.S. Ok, now I got it. It's not ed video, but ad for sponsor. Well you should retitle the video right.
You can split components further into views and controllers sure, but you also can choose not to and do it how I did, it's perfectly valid. And yes, in the last example I showed the model layer too, did you watch until then? ☺️ And lol, I would've made this video with or without the sponsor my dude
you explain really good but in the compound component, you use the onClick in the option which does nothing, this is the second example you do that lead to a broken component , its better to make component that actually work so people can see the use case
You could, but then you need to tell it what posts to fetch. If the home page, fetch home page posts, if user profile, fetch user posts. Easier to have that fetch in the respective pages and the component just render them imo
10:00 you are passing the state setter as prop which is anti pattern by itself. Instead, the callback should be passed and state setter should be called inside handler of that callback
I don't understand why home page is responsible for getting the posts, in single responsability example. Shouldn't it only be responsible for rendering all the page components and PostFeed to be a feature component and get what it needs for its child components?
Imagine you have a reusable component PostFeeds. Its used in HomePage for displaying articles, in another area its used for displaying some other feeds. If we fetch data in a reusable component, then we would need to create a separate post feed variant. End result would be like ArticlesPostFeed, GroupPostFeeds, etc. By having the fetch logic in HomePage, we have achieved single responsibility in PostFeed because now its just for displaying posts and can be used again without needing additional wrapper like ArticlesPostFeed, GroupPostFeeds, etc. p.s. if you know your PostFeed is not reusable, you can keep fetching inside it.
@@abubakar.khawajaWhile I agree that there can be different nuances, I still believe you can achive it in different ways (passing a props maybe) I usually don't like the ideea of a home page loading things needed by the children. Having in mind single resposability, I believe that if we have a Postfeed component, it should be responsible for getting the post. Not just render them. All components will render something, in this case we could say that homepage doesn't respect the single resposability because it is getting the post and render the postfeed. What if we want to add some filters to the postfeed, how we would implement it? What components we would need to change? We would start passing different functions as props to the child and update the state of homepage.
Talks about SRP, doesn't do SRP in its best way: your outer component does not do one thing, but two: it renders the component and it fetches the data. Therefore you break SRP 😬
So how I see SRP is that it shouldn't just have a few lines of code on one specific thing, but rather one responsibility. That's the R in SRP. The HomePage is responsible for the rendering of the HomePage, which includes fetching the posts and passing the data to all sub-components
fair enough, but that's mostly because of setting up the context + a custom hook, which isn't necessarily required for a simple select component that is pure UI
Great video! I only disagree in the single responsability part, because in many cases it's not worth the effort of splitting things up, and you didn't dig into how to decide when to use the pattern.
I would argue that splitting should be the way you build them in the first place. If you always build small and with a single responsibility, no matter the project you end up benefiting imo. That's why I didn't mention anything about when to use it in the video
If you have a PostFeed component that is responsible for rendering the posts, why fetch them in the parent component? If PostFeed has the responsibility to deal with the post feed (obviously), isn't it better to let it fetch its components and remove this responsibility from the parent?
You could, but you'd still have to pass something from the homepage. Because if you re-use PostFeed somewhere else, like a ProfilePage, you need to tell it which userId to fetch from. So the PostFeed still needs info from the parent to fetch. So at that point, makes more sense to do the fetch in the parent with the correct filters, and just use PostFeed to render them!
You started off by talking about the single responsibility principle, but then went and assigned multiple responsibilities to it. The page component would, indeed, be responsible for orchestrating the required components, but it shouldn't deal with container styles - that's something that should be delegated to either a "layout" or a "template" component that accepts various implementations as child elements. While it's true that the page should also fetch the overarching data that is required to display everything, filtering it is not its responsibility - that's something that should be handled by a different component and upon successful filtering, the page component would update its state with the new data. What if I have a smart component several layers deep that needs some data that is not needed anywhere else? Would you also fetch in the page component and pass it down through prop drilling? I would argue that you shouldn't and rather let that component fetch what it needs to work with, so that the page component would only deal with state that is important for the whole page.
Great comment! Sure, you could use a layout if it's a generic style that applies to all pages. But for laying out the post feed and how that is styled, that's the home page. Does it go at the top or at the bottom, is it full width or next to a search bar, etc. That's home page responsibility. Also, the actual components that will filter are separate, sure. But the home page needs to hold and pass a callback to that component to receive the updates, and then filter the posts to display. That's what I meant! And to the third point, it really depends. You can have self contained components that fetch their own data, or you can choose to pass it from the home page. There's no right answer and it really depends on the specific context imo. Could've had PostFeed fetch its own data and only receive some parameters from home page to fetch with for example
'single responsibility principle' is an priniple. a.k.a. a guideline. Not a Design Pattern. EDIT: I see 0 Design Patterns here. Just code separation, no technical problem solving.
TBH, this was a time waste video for me as I always come to this channel for intermediate to advanced content and that was my Notion until now that you focus only on my type of audiences but gotta be mindful next time :)
Select component are not good enough to show it even for junior developers, cause even within Design Pattern its a bad practice, cause you store the view and the logic of the context inside one file, that incorrect in any case.
I don't think naming Design Pattern is right for this type of content. You are presenting good practices for React and Single Responsability Principle Anyway, interesting video, keep up the good work!
@@cosdensolutions I would consider them as good practices. If you take into consideration the definition of design pattern (Design patterns are typical solutions to commonly occurring problems in software design.), those are solutions exclusively mapped to frontend frameworks. As I've just said, it's a personal opinion based on this definition.
compound component is just adding more layers of complexity, just keep everything simple and easier we dont need a context or a hook for a simple select that absurd
The idea is that all of that complexity is abstracted in that component once, then you don't worry about it. And using context prevents you from using the Option component in something other than a select, and then adding props and logic in it to fit both use cases. That pattern doesn't scale at all and will lead to a lot of problems. That's the benefit of compound components
I think this is really meaningful, especially for beginners who don't know the ways to think about React. But I will definitely make more videos like these!
I think it is important that young developers or aspiring engineers should be exposed to "politically correct way of doing things" because as a lot will later find out that it is harder to unlearn bad habits than to acquire new good ones. Design Patterns: Elements of Reusable Object-Oriented Software (by the Gang of four) is probably one of the most influential books written in computer science history that discuss the "CORE" of OOPs patterns that are absolutely used in JS meta frameworks. Anyways.. good luck
Well, the thing is that the classic go4 design pattern is not always applicable to React codes. I think this video delivers more concrete, head-on, and easier design patterns for relatively new developers to follow.
Hope you enjoyed the video! I also have a really cool and unique course that will teach you way more than this video. You'll learn how to build an actual complex project with React. It's called "Project React" and you can find it at cosden.solutions/project-react. Also, I have a free weekly newsletter called "Import React" with tutorials, news, and cool stuff about React! You can sign up at cosden.solutions/newsletter?s=ytc
A series in design pattern would be great
I agree!!
Me too!
Yeaaaa
Someone please remind me if/when its made.TIA.
It's always interesting to see where someone draws the line on single responsibility.
I am grateful for your tutorials. Especially the React Query tutorials.
I love your way of explaining things. Understandable and calm language, as well as not overloaded code, which is really nice to read.
Thank you so much for the time you invest in the making of these videos. Best React content available.
Thank you for the kind words!
Bro can you help me with a small issue I'm having concerning react props and typescript ? Thanks in advance
I have done all of those things before, glad to hear that they are good practices 😅
Love your videos man. Find them very helpful. I’m an experienced backend developer, finally biting the bullet and reaching myself react (if that’s at all helpful info).
Making my way through every videos you’ve made lol
Hahaha nice dude! Good luck 🤙
Hi, Don't you think that HomePage violates the Single responsibilities principle? Because the HomePage component fetches posts, in the future it may be responsible for sorting posts, etc. + it renders content in the future HomePage also can render something else, which may also require fetching data. Isn’t it better to move the state and fetch to the PostFeed component and fetch the posts there? In this case PostFeed will be responsible for posts logic. If we want PostFeed to be reusable, we can rename this component to just Posts (will accept posts as props) and create a wrapper e.g HomePagePosts which will have a posts state and fetch the data and pass this data to the Posts component through the props? What do you think?
This.
Great question! So first, I don't think it violates it at all. Any React component needs to return something, so that by default makes it responsible for what it returns. In most cases, that's JSX so it's responsible for returning that and providing everything those components need.
What I meant with the single responsibility principle, is that each component should have only one obvious job. In the HomePage, that job is to hold the state needed to render itself. So that means holding and fetching the posts, or if there's sorting implemented then holding the function that sorts the posts and passes it to the component that sorts, and anything else that it needs for its own content. The single responsibility here is: render the HomePage. Everything else it should delegate to other components.
So you could've fetched the posts in the PostFeed component sure, but then the HomePage would've needed to hold some object with params to fetch with. So then that would become its responsibility. If you had a ProfilePage, it would hold different params such as the userId to fetch only those posts. That would be its responsibility.
Then you can have other components, like the PostCard which is only responsible for rendering a single post. But that may mean it can hold some state, or fetch some data that it needs to render the post, or even filter stuff there. It still falls under the responsibility of: render a Post.
That's the key, it's not about actually doing one single thing, but being responsible for one thing and holding all the code necessary for that one thing, even if that means multiple states and effects and props passed to other components!
@@cosdensolutions thx for reply)
what you could also do is extract all posts fetching logic in a custom hook (usePosts) - as explained in the last design pattern in the video.
In this hook, you can move the fetching part that is present in the HomePage. Imagine having filters, sorts, different views options (as cards, as list, etc). The HomePage would have lots of logic in it + testing would be a nightmare and not possible to do unit testing correctly -> you would render a giant component every time you want to test isolated capabilities: filters, sorts, etc
@@zizzz10 great solution, also thought about this
Much awaited video ❤ Loved it
Don't you hate when you know that there is a better way to do something, but you don't know the right terms to search for? I needed a compound component on a recent project but ended up coding my way around it. Thanks for these videos, when developers can talk to humans it's their responsibility to help. I was a tutor for a few years. I bet making these videos has helped you develop even better.
I totally know what you mean! Many times have I searched for something but didn't know the specific words. For what it's worth, AI helps with that a lot. You can try describing your thing and it might give you the right answer
@@cosdensolutions I just signed up for co pilot but I’m not in the habit of leaning on that yet. The video sponsor looks like a cool way of setting stuff like that up too. If they integrate storybook into that it will be a power house.
I absolutely relate to that. ChatGPT is a great help as it feels like you're talking to a real mentor. Unlike asking in StackOverflow whose egotistical users will either flag your question as duplicate even if it's not or mock/make fun of whoever is asking. Then there are those articles that most of the times don't help at all. The experience is vastly different than using a search engine.
Chat GPT is great for finding these "key terms"
really like the custom hook tip at the end!
this channel should be included in the "hall of fame" you are the only one teaching real world react.
damn, thank you! That's exactly what I'm trying to do!
Wow , Great explanation !
Thank you : )
The only thing I would say about having your fetching and state in your parent component is that when you update that data, your whole page will reload, not just the componants using the data.
Loved the custom hooks part!❤
best vid I've ever seen 👌
The last design pattern greatly helped me structure my code better. Thanks for the video. Appreciate if you can add some more design patterns.
will have another video on design patterns tomorrow or monday!
Thanks for such quality videos. A series on design pattern would be appreciated.
a series it shall become!
Thanks a lot bro, really great video
Congratulations 🎉 👏🏼 for your first 🥇 sponsership 🤝
and as always infotainment video ❤
Thanks to show this!
yes ,with REACT if you can do a design patterns series practical real-world example would be really great
Hi, I wonder about the last pattern 'extract useEffect to other files', if we have too many dependencies related to useEffect such as the variables from useState for checking, how can we handle that?
Trust whenever u have a dependency that has dependencies, there's a way to refactor ur code to get rid of that useEffect
Excellent. thanks for sharing design pattern in react.
Amazing new video lot of new concepts learn how to manage large workflow.
@Cosden Solutions - 2:10 You are not supposed to use side effects directly like this in React components. You should make a custom hooks / utility functions to adhere dependency inversion principle and separation of concerns principle...
It also creates questions on what is the source of truth for posts? What if the posts on the server updates and we want to display those to the user? Also during that first render - even if the api calls are cached - it will have posts being null. This is a massive anti-pattern for so many reasons!
Last one : chef's kiss.
I am wondering about useSelecContext hook in 10:39. Why do you use useContext in a single component. It this used somewhere else in code except that select component that is shown on video? What it used it for? Maybe for taking the value in a parent komponent or what?
Hello sir, could you please bring a series on advance senior developer code for instance an open source react project code like a ui library. How they code, what should be the correct way to make a feature and so on. BTW love your content
Interesting ideas, thanks a lot will think about it them! ☺️
4:38 hello, terminal app name?
Hey Cosden, thanks a lot for sharing your knowledge with us. Which monitor do you use for your mac? I have been struggling to find a decent one with crisp text for my mac mini :(
I have a samsung, not sure which model but it's 34 inch with 2k resolution @ 144hz. That's good enough for me for now!
How come I'm not subscribed to this channel. Your contents are amazing
well, hopefully you are now :D
@@cosdensolutions of course I am now
SRP is a good pattern but can lead to the following drawbacks: excessive fragmentation, increased boilerplate code, decreased readability, difficulty in debugging, and an increased onboarding time for developers.
For small and even some medium-sized projects, sometimes it's just simpler and easier to AVOID breaking things down into multiple responsibilities and files. Sometimes it IS more readable if it's in a single place.
I would love to pay you for one on one tutoring, you sound like you really know what you're talking about.
I currently don't do 1v1 (but that might change in the future). However, I am soon launching a course that takes everything I've learnt over my career and puts it into a package that goes significantly beyond what my videos do. It's coming in a month and a bit!
Great video! However, there is something that is bothering me. Why should we reinvent the Select behavior when it's already implemented by the browser?
But the pattern is awesome and should be utilized.
Generally it's good to have your own components that wrap the browser elements just so you can add any customisations you need there and have them apply to all of your app, instead of repeating it every time you use a select input. You can style them, add additional props, etc all in one place to re-use
Never seen or used compound component pattern before. Very interesting. I'm curious in what other real world scenarios it would be beneficial to use. Thanks!
they use it a lot in component library e.g antd, bootstrap... you should check it out
Great share of knowledge
Is the last example correct ? The useSignInHooks will be triggered on each render no!?
yes, that's not a problem at all. Even how it was before it would trigger every render
@@cosdensolutions by rerender do you mean each state update or refreshing !
isn't wrong to send analytics event on each state update ?
We are missing HOC, composition etc design patterns. This video is confusing 😞, could you please provide a link to these videos in this video. Thanks
2:35 i can't get it i thought the initial state can only be string,number or null...why is there a component there?
Its name of Type not a component, brother is using typescript. :')
Why is every react component put in a separate file, even the ones that are related to each other and could be easily navigated within the same file?
Thanks for sharing.
any update when will you make a tut on React Router.
Its planned for a couple of vids from now! Don't worry it's coming ☺️
@@cosdensolutions thanks whatever you teaches directly goes to my mind I am too addicted to your teachings thanks.
Thanks for the Video , but i see an issue with Props Drilling! we are passing the posts to 3 child components!
can you explain why this is a bette practice than creating a posts context ?
posts is only passed to PostFeed. PostFeed then maps over the posts and passes a post to PostCard. This is not prop drilling, this is just normal React! A context wouldn't make sense here!
@@cosdensolutions thank you for the feedback and explanations!
That was a really interesting video! Thanks for sharing.
A question about extracting logic into Hooks - how do you share state from the hooks back into the component itself? Would you return a big object full of properties similar to how useState works?
the thing that I would personally do is just returning the properties that i need. For instance, if i fetch some data and put it in the state, i'll then just return the value from the state without anything else (apart from common utils like isLoading, error etc...), in order to let the component consume only the things that it actually needs
Yes you return everything that you need! Usually in the form of an object with the properties inside so that you then use them with the same name in the component!
Wow this helped a lot
About the Select compound of components, I don't understand how could I end up using an Option component NOT under a Select component...
how did you make the functions sticky in your vscode ?!
it's a setting in vscode!
Does mightymeld work in monorepos?
Great video btw! You got yourself a new subscriber 🍻🍻
Great video thanks, could you please tell us what is the name of last pattern you mentioned?
Extracting logic into hooks
I would argue that PostFeed should handle the Post fetching itself. Makes more sense than the HomePage which is really just a visual container.
I wouldn't, because you would also use PostFeed in the UserProfilePage for example, where you'd need to fetch all posts of a specific user. So you would need to pass some sort of filters from the HomePage and UserProfilePage. So at that point, just fetch them there and let PostFeed display them only
@@cosdensolutions Passing the filters seems fine imo
// Home.
// Profile.
Or similar. But to each their own, and hard to say without a larger app context. Cheers, love the vids.
It also creates performance issues, especially when we want the user to poll the server occasionally to get the latest data. If HomePage has multiple components which might all require their own data obtained from API calls which are all placed in HomePage, then when any of these updates, all of the components will re-render. Not a problem in toy projects but can be a major one in larger ones.
PostFeed with potential filter props, and then using something like React Query makes a tonne more sense, and would be much more performant. Again, in larger projects, it would make it much easier to look at the logic since it's colocated with the appropriate component. The main con against this is creating the need to the mock RQ or your fetching API/hook when testing your component instead of simply sending it an array of Post objects. However, that's not particularly difficult to do.
can we isolate the logic code in a components that uses that conditional rendering depending on states for example?
yeah you could
@@cosdensolutions mmmmmm, does it contribute anything to performance or only for readability and clean code approaches?
Awesome! You could highlight keywords.
Can we get this codebase or any github reop to view this example?
I've started working for my first time at a company at a level of junior. I've already extracted a topic dashboard page into multiple hooks for easier management. I was required to hooks which was used in another hooks,, is this a good idea?
yeah, sounds reasonable, I use hooks within hooks all the time!
Hello, on compound compoent how can you access selected option on component your are using it?
Pass a callback from the parent to call onChange and get it that way!
The Select context option feels unnesarily complex. Custom hooks + useContext for a native form element? You mention that it's nice because now it's a simple and reusable component, but you've created something that is finicky, difficult to understand and hard to maintain. That's the opposite of a senior design pattern.
The SRP is arguable here, for this example, homepage component should not be responsible for fetching posts, that's a responsibility for Posts component to do, imagine that homepage has other components that need some data from an API, so the homepage component will be a mess, therefore, we'll be violating SRP. Also the last patten is arguable indeed, if we do that for every component, then we're losing colocation principle which I think it's more meaningful than just move things around, instead I think smart/dump components pattern would make much sense in such situation instead of using custom hooks. Thanks for the video though
Great work I really learned a lot! One question for minute 14:00 would you also make a sepearte file Component.helpers.ts for functions like const handleSubmit e => {} and other functions? Also how would you do it on server components where you can't use hooks?
Can you do a video about select.option. Watched it 10 time in speed 0.75.. I don´t get it.
I get why it need to be in a select. But I don´t get the Select.option tag
a full video on this is coming!
Really love theses kind of videos! Thank you! One question, and sorry if it would be obvious, but I really liked the last pattern, bit how would it be implemented if I need a control state? Or that would be more like the second pattern shown?
I'm not sure what you mean by control state, but extracting that in a custom ".hooks" file is no different than having that code directly in the component. So you could have that custom hook receive props from the component or from above, and even return a value too. This will work exactly in the same way, with the only difference being that now everything runs through and from this extra file
@@cosdensolutions sorry, sometimes I'm not so clear in english :(
What I meant is if I need that state that (also) controls something outside of that .hooks file. Although I might be looking wrongly at the problem x solution.
~ just to make an excuse ~
Been a couple months I'm not coding, kinda discouraged, so maybe that's why I'm not looking at this properly.
@@danieldk5148 in that case, you need to pass the callback function to update that state through props to this component, and then pass it to the hook in .hooks. Then call it in there and it will update wherever the source is!
@@cosdensolutions thank you!
should I have one test for my Component.tsx and other for my Component.hooks.tsx? or one test for both of them? Excellent video!!
please let us know the open source project u were taking about in you tube shorts
Great Content!
But I see an issue in the video, you said "Single Responsibility Principle" as a pattern, which I think is not true." Single Responsibility Principle" is not a pattern. It is one of the principle belongs to SOLID principles. If I'm wrong. Do clarify this thing kindly.
Hello sir, please make a video on feature driven folder structure a.k.a screaming architecture - no youtuber has covered this till now and i am expecting from you .....
That was helpful.
Lovely !
and i would like to know how to give answer please explain about your fronted project architecture ? give your sample react project architecture example .!
SRP is not a design pattern but a SOLID principle.
And the first ex is not quite good.
should only return JSX (view layer)
should only return JSX (view layer)
should fetch data (model layer)
P.S. Ok, now I got it. It's not ed video, but ad for sponsor. Well you should retitle the video right.
You can split components further into views and controllers sure, but you also can choose not to and do it how I did, it's perfectly valid. And yes, in the last example I showed the model layer too, did you watch until then? ☺️
And lol, I would've made this video with or without the sponsor my dude
Can you please create a complete react course.
Absolutely, working on it as we speak! I'm doing something unique and way better than anything else I've seen out there ☺️
Patiently waiting@@cosdensolutions
you explain really good but in the compound component, you use the onClick in the option which does nothing, this is the second example you do that lead to a broken component , its better to make component that actually work so people can see the use case
why not fech posts in the postFeed. PostFeed is the owner of these posts. I'd do the fetching there
You could, but then you need to tell it what posts to fetch. If the home page, fetch home page posts, if user profile, fetch user posts. Easier to have that fetch in the respective pages and the component just render them imo
10:00 you are passing the state setter as prop which is anti pattern by itself.
Instead, the callback should be passed and state setter should be called inside handler of that callback
what makes you say it's an anti-pattern?
interesting topic, just leaving comment to get notified when someone replies
I don't understand why home page is responsible for getting the posts, in single responsability example.
Shouldn't it only be responsible for rendering all the page components and PostFeed to be a feature component and get what it needs for its child components?
Imagine you have a reusable component PostFeeds. Its used in HomePage for displaying articles, in another area its used for displaying some other feeds.
If we fetch data in a reusable component, then we would need to create a separate post feed variant.
End result would be like ArticlesPostFeed, GroupPostFeeds, etc.
By having the fetch logic in HomePage, we have achieved single responsibility in PostFeed because now its just for displaying posts and can be used again without needing additional wrapper like ArticlesPostFeed, GroupPostFeeds, etc.
p.s. if you know your PostFeed is not reusable, you can keep fetching inside it.
@@abubakar.khawajaWhile I agree that there can be different nuances, I still believe you can achive it in different ways (passing a props maybe)
I usually don't like the ideea of a home page loading things needed by the children. Having in mind single resposability, I believe that if we have a Postfeed component, it should be responsible for getting the post. Not just render them. All components will render something, in this case we could say that homepage doesn't respect the single resposability because it is getting the post and render the postfeed.
What if we want to add some filters to the postfeed, how we would implement it? What components we would need to change? We would start passing different functions as props to the child and update the state of homepage.
I did not get why you call Single responsibility principle from SOLID a first design pattern?
it is not a pattern, it is a principle.
Talks about SRP, doesn't do SRP in its best way: your outer component does not do one thing, but two: it renders the component and it fetches the data. Therefore you break SRP 😬
So how I see SRP is that it shouldn't just have a few lines of code on one specific thing, but rather one responsibility. That's the R in SRP. The HomePage is responsible for the rendering of the HomePage, which includes fetching the posts and passing the data to all sub-components
I find it wild that it takes 70 lines of code to make a select component in React. Great video though.
fair enough, but that's mostly because of setting up the context + a custom hook, which isn't necessarily required for a simple select component that is pure UI
Great video! I only disagree in the single responsability part, because in many cases it's not worth the effort of splitting things up, and you didn't dig into how to decide when to use the pattern.
I would argue that splitting should be the way you build them in the first place. If you always build small and with a single responsibility, no matter the project you end up benefiting imo. That's why I didn't mention anything about when to use it in the video
thanks
If you have a PostFeed component that is responsible for rendering the posts, why fetch them in the parent component? If PostFeed has the responsibility to deal with the post feed (obviously), isn't it better to let it fetch its components and remove this responsibility from the parent?
You could, but you'd still have to pass something from the homepage. Because if you re-use PostFeed somewhere else, like a ProfilePage, you need to tell it which userId to fetch from. So the PostFeed still needs info from the parent to fetch. So at that point, makes more sense to do the fetch in the parent with the correct filters, and just use PostFeed to render them!
can I have github repos?
Great Video!
i think the right name of the pattern is not feature components, is compound components,
I talked about both in the video!
Thnx
I learned nothing, but it should be a good introduction for begginers maybe
That's mostly who my channel is for!
this is it AWESOME!!!🎉
The useSignInPage does not have a single responsibility.
"senior level"
You started off by talking about the single responsibility principle, but then went and assigned multiple responsibilities to it.
The page component would, indeed, be responsible for orchestrating the required components, but it shouldn't deal with container styles - that's something that should be delegated to either a "layout" or a "template" component that accepts various implementations as child elements.
While it's true that the page should also fetch the overarching data that is required to display everything, filtering it is not its responsibility - that's something that should be handled by a different component and upon successful filtering, the page component would update its state with the new data.
What if I have a smart component several layers deep that needs some data that is not needed anywhere else? Would you also fetch in the page component and pass it down through prop drilling? I would argue that you shouldn't and rather let that component fetch what it needs to work with, so that the page component would only deal with state that is important for the whole page.
Great comment! Sure, you could use a layout if it's a generic style that applies to all pages. But for laying out the post feed and how that is styled, that's the home page. Does it go at the top or at the bottom, is it full width or next to a search bar, etc. That's home page responsibility.
Also, the actual components that will filter are separate, sure. But the home page needs to hold and pass a callback to that component to receive the updates, and then filter the posts to display. That's what I meant!
And to the third point, it really depends. You can have self contained components that fetch their own data, or you can choose to pass it from the home page. There's no right answer and it really depends on the specific context imo. Could've had PostFeed fetch its own data and only receive some parameters from home page to fetch with for example
I don't think it matters seniors are still going to use the most fkd up pattern in the existence
U forgot the lazy loading that component. it could be a huge problem
Nah because they go together so they should be loaded at the same time
'single responsibility principle' is an priniple. a.k.a. a guideline. Not a Design Pattern.
EDIT: I see 0 Design Patterns here. Just code separation, no technical problem solving.
looks like you were in hurry, please make video when you have more free time and good sponsor
TBH, this was a time waste video for me as I always come to this channel for intermediate to advanced content and that was my Notion until now that you focus only on my type of audiences but gotta be mindful next time :)
Select component are not good enough to show it even for junior developers, cause even within Design Pattern its a bad practice, cause you store the view and the logic of the context inside one file, that incorrect in any case.
I don't think naming Design Pattern is right for this type of content. You are presenting good practices for React and Single Responsability Principle Anyway, interesting video, keep up the good work!
what would you name this as? And what would you consider design patterns in React?
@@cosdensolutions I would consider them as good practices. If you take into consideration the definition of design pattern (Design patterns are typical solutions to commonly occurring problems in software design.), those are solutions exclusively mapped to frontend frameworks. As I've just said, it's a personal opinion based on this definition.
Single responsible principle is one of the solid principles by Bob Martin. Is a guide not a pattern.
compound component is just adding more layers of complexity, just keep everything simple and easier we dont need a context or a hook for a simple select that absurd
The idea is that all of that complexity is abstracted in that component once, then you don't worry about it. And using context prevents you from using the Option component in something other than a select, and then adding props and logic in it to fit both use cases. That pattern doesn't scale at all and will lead to a lot of problems. That's the benefit of compound components
Amazing
explanation is too fast, not able to understand the compound components
i thought we were going to learn about factory, oberserver, singleton something meaningful not this!
I think this is really meaningful, especially for beginners who don't know the ways to think about React. But I will definitely make more videos like these!
I think it is important that young developers or aspiring engineers should be exposed to "politically correct way of doing things" because as a lot will later find out that it is harder to unlearn bad habits than to acquire new good ones. Design Patterns: Elements of Reusable Object-Oriented Software (by the Gang of four) is probably one of the most influential books written in computer science history that discuss the "CORE" of OOPs patterns that are absolutely used in JS meta frameworks. Anyways.. good luck
Well, the thing is that the classic go4 design pattern is not always applicable to React codes. I think this video delivers more concrete, head-on, and easier design patterns for relatively new developers to follow.
@@noNullMomentsnever seen someone apply oop patterns you listed in react😅
@@rahulsingh-hn3fyth-cam.com/video/CWkD2kP6Wug/w-d-xo.htmlsi=iNRRUJIlGY9zJbpp 😮😂😂😂