I don't know if this kind of content is actually boring to others but I must say this kinda stuff is what actually helps you become a "good" developer. I can't even stretch the importance of these kind of contents enough. I appreciate the effort, keep it up!
Hie, can anyone here explain me will it be a good practice to create do many files for one component rendering. i started react a few months ago and now i have a huge project which has 25+ pages. pages become messy and i sm planning to remove the uglyness, can anyone suggest me the best way for it
In addition to styling reasons mentioned by Darius, the at 14:44 is also necessary to render the ProductList component in the event that the products array is empty. Otherwise if the array was empty, you'd get an error because the .tsx file isn't returning a component to render.
Although I've only been following you for a short time, I find what you do amazing. I love the way you explain things so clearly. You are truly great. Thank you!
I am here for these kinds of videos. Anything that helps apps scale. Really appreciated. In my scenario example product card may look different in different site areas, so I create extra component props launch as inHeader, in body, inBodyBtm and than render there any additional components I may need to show up an my parent component
I would instead make product card a compound component, and let the parent plug and play the elements it wants in whatever order. Passing props around works, but doesn't scale well at all!
I wish more of my colleagues (and UA-camrs making tutorials) did this. It always makes it so much easier to work with for me. One issue that I do sometime face doing this though, is with forms etc where a ref is required. Would be useful to have a part 2 that covers these more complex scenarios
Very detailed explanation sir. I learned alot. I would start implementing custom hooks more in my applications to separate too much logic from my components
00:04 The single responsibility principle emphasizes that a component should have one and only one reason to change. 02:25 Single responsibility principle ensures code maintainability and bug identification 04:30 ProductsPage component is violating the single responsibility principle 06:40 Creating a custom hook for fetching products in React 08:39 Implement single responsibility principle in React by delegating specific tasks to separate components. 10:52 Delegate UI logic to separate components for reusability 12:54 Implementing Single Responsibility Principle in React 15:10 Separating responsibilities for components in React
SRP is only the first step down the road, if you want to become a better developer it's completely worth it to take some time to learn all the principles of SOLID and understand how to apply it efficiently into your projects. Great job with the explanation, maybe you could try the Open/Closed Principle next? Thanks.
Thanks for that, just wish all applications was that simple. the one I just took over at work is a nightmare... looks nothing like yours :) Keep up the excellent work!
Thank you for this video. Your code is really great! It is really important to teach this idea! The value of it is huge and is really important to follow this design principle. However! You cannot apply SOLID to react directly. SOLID was made for OOP. You also violate this rule in your previous video if you use this principle as it was described in SOLID. Single responsibility principle is also not single feature principle. It says - you should have ONE REASON to change. It says nothing about “it does one thing”!!! This is important! I would suggest to never use S in connection to the SOLID in react. In is even more to U in CUPID principles!
Hi, well explained mate! I'm wondering if you have also a more advanced example where you do CRUD (refetching data after creating a new item for example).
Awesome and clear explanations! I was curious about exports. Here u are using default exports but I see a lot of codebases use named exports. When would u choose one over the other?
@cosdensolutions In my experience named exports are easier to refactor cause the import name will change but with default, it can leave the old one which can be confusing and it will not even error
Would it be better if we move the conditional logic for showing loading or error or products inside the extracted components? So the productspage will have no conditionals
Nope, it's the responsibility of the products page to decide it wants to show something on loading. The loading component only has the responsibility to show loading UI
I would also pass the loading, and error props inside of these components and would do the checking inside of them. But that is a matter of taste. Anyway, things shown in the video distinguish juniors from more experienced guys.
Thank you so much for this content! I wonder how you would define the layout of the several components in the ProductPage? Inside the component or would you put it somewhere separately?
Would an higher order component make sense in order to manage the loading, error and display component since on a single page you can have multiple request for different resource ?
I feel like you shouldn't be moving things around based on the single responsibility principal, The code at 9:00 was probably the best version of this code. You can clearly tell the output of the UI based on state and you don't have to navigate to different components that only do one thing resulting in you trying to keep multiple pieces in your head, Things living in one place makes it easier to understand and debug (big components are not inherently bad). You should be moving things into their own components based on re-usability and functionality. You would want a loading and error component not because they should only have one responsibility but rather because you want to reuse them several times in your app. And you might want to move the product UI into it's own component if you needed some logic to run per component.
What vscode extensions / configurations do you use to the have missing import indication in the code (red underline under what is missing) and when you click on it - it adds the import automatically? (As you do in minute 06:52 in the video) Thanks :)
depends on what you want to unit test, I usually wouldn't unit test any of these components. I would only unit test UI components and components that are designed to be re-used across many places. In that case I'd colocate the unit test file with the component and write all the tests there. I do most of my testing with e2e integration tests generally
can you do a video on composition pattern with a more real world apporach instead of a simple component showing a message that is shown on the various videos about composition pattern?
I should ask you, is it good to just check for products(array) in this way? Because empty array will also return true, I'm usually checks for !!pruducts?.length for that. Am I doing it wrong?)
In case I need to implement the "enabled" prop for useQuery, how can I do that? Is it enough to pass the 'enabled' prop and simply include it in the useQuery?
@@cosdensolutions Thanks i made some changes in my project `import { Notes } from "@prisma/client"; import SingleWobbleBadge from "@/components/Dashboard/Home/SingleWobbleBadge"; import SingleWobbleDescription from "@/components/Dashboard/Home/SingleWobbleDescription"; import SingleWobbleImage from "@/components/Dashboard/Home/SingleWobbleImage"; import SingleWobbleTitle from "@/components/Dashboard/Home/SingleWobbleTitle"; interface SingleWobbleProps { wobble: Notes; } export default function SingleWobble({ wobble }: SingleWobbleProps) { const { category, createdAt, description, imageUrl, title } = wobble; return (
); } ` what do you think earlier i am rendering all in same component
So, do you mean that, if I have 100 pages, I should create 100 custom hooks just to fetch data from API? What about DRY? Why we can’t just create 1 universal hook and use it anywhere?
Well yeah, if you have pages, users, posts, comments, and 100 more entities you should make a hook for each. Although you won't in practice. If you have 100 user pages, one hook is what you need
You may have 100 pages but also your queries wont be much different. So you can implement an universal-like hook for 'Users' which requires the optional query params (like createdAt-updatedAt-roleId etc.). In every single page you can customise your query.
The Approach is Good Until If you need to Fetch The Product based on Pagination Data Definitely you must place your fetching logics inside the components that's the better way we can't pass the pagination values to hooks everytime right ?
I usually hold the fetching logic in the page component and the ProductList component can just take a callback whenever it reached the end of the list to fetch more products
This is good, but the single responsibility principle doesn't necessarily mean everything should do just one thing. It could be things that are closely related as well.
I prefer the product-list should just be part of the page component because the logic won't change or grow overtime. The entire logic is basically a loop and i feel that's too small to be extracted.
So all of my videos are kept super simple right? It will never be just that amount of code. In real projects it's often way more so this pattern applies. Sure if it's a personal small project, you can get away with putting everything in one main component, but I'm not teaching you to build simple projects
Very informative video indeed however i don't think this was some sophisticated example. Would highly appraciate some more complicated examples of solid. Anyway, thanks for posting!
Ok so I will comment on this. I have snippets, however I just made the change from arrow functions to declaring them the old school way and I didn't get to the snippets yet lol. But it is fixed in a couple of videos haha
I do most of what you're suggesting here. But, I would have suggested that unless your ui components need to be reused, it is actually easier to keep them in the safe file. If you're extracting UI components to separate files and they are not reused anywhere else. That's just silly. And actually harder to understand imo.
It's not silly. I'm teaching how to build complex apps, and in complex apps, you'll always re-use these components so defaulting to this pattern makes sense
I don't know if this kind of content is actually boring to others but I must say this kinda stuff is what actually helps you become a "good" developer. I can't even stretch the importance of these kind of contents enough. I appreciate the effort, keep it up!
That's what my content is for! Glad you enjoy it! 🤙
Excatly , I think this too . This is the best react app architecture in my opinion , keep it up!
This is the kind of video you don't find on a react course 🎉
I'm actually making a React course that will have much more of this and in much greater detail and scope, stay tuned!
Hie, can anyone here explain me will it be a good practice to create do many files for one component rendering.
i started react a few months ago and now i have a huge project which has 25+ pages. pages become messy and i sm planning to remove the uglyness, can anyone suggest me the best way for it
There are so many React Tutorials out there but no one shows how to structure the components, Thanks for the great content pal!
will make many more videos for sure. Also working on a full React course that goes way beyond what my videos do, so stay tuned 🤙
Your tutorials are easier to understand and clear to the point, thank you so much for your valuable guidance....
In addition to styling reasons mentioned by Darius, the at 14:44 is also necessary to render the ProductList component in the event that the products array is empty. Otherwise if the array was empty, you'd get an error because the .tsx file isn't returning a component to render.
💯% helpful, been using react for more than 2 yrs but this makes a lot easier. i'm gonna follow this in our projects. Thx for great tutorial.
Although I've only been following you for a short time, I find what you do amazing. I love the way you explain things so clearly. You are truly great. Thank you!
I am here for these kinds of videos. Anything that helps apps scale. Really appreciated. In my scenario example product card may look different in different site areas, so I create extra component props launch as inHeader, in body, inBodyBtm and than render there any additional components I may need to show up an my parent component
I would instead make product card a compound component, and let the parent plug and play the elements it wants in whatever order. Passing props around works, but doesn't scale well at all!
Moving the useQuery to new file made a huge difference for me. Thank you very much for these kind of video. Really helpful.
Because of ur videos my react project code gets better, keep making more videos, so helpful ❤
I wish more of my colleagues (and UA-camrs making tutorials) did this. It always makes it so much easier to work with for me.
One issue that I do sometime face doing this though, is with forms etc where a ref is required. Would be useful to have a part 2 that covers these more complex scenarios
I had a light idea of what this was but this video took it to the next level, thanks a lot
Very detailed explanation sir. I learned alot. I would start implementing custom hooks more in my applications to separate too much logic from my components
never fail to amaze me, thank you for this tutorial
Dude, you are doing quite an excellent work with React.
You remind me of what ArjanCodes does for python.
00:04 The single responsibility principle emphasizes that a component should have one and only one reason to change.
02:25 Single responsibility principle ensures code maintainability and bug identification
04:30 ProductsPage component is violating the single responsibility principle
06:40 Creating a custom hook for fetching products in React
08:39 Implement single responsibility principle in React by delegating specific tasks to separate components.
10:52 Delegate UI logic to separate components for reusability
12:54 Implementing Single Responsibility Principle in React
15:10 Separating responsibilities for components in React
This channel is amazing, thank you!
This channel is a treasure, too bad I didn't find it long ago.
Thank you for the amazing content.
어느정도 이해가 됐습니다. 코드가 아주 간결해지네요. 헤메지 않도록 파일 이름을 잘 작성해야겠어요
I think we have to keep in mind that it is important to keep balance between KISS and Single responsibility principle
Great explanation this series of design patterns will be great
Finally, keep going in this tutorial to complete all solid principles using react.js with typescript
All the examples we see talk about the list. It would be nice, an example of creating, editing and deleting, along with the save method, using SRP
very clear and precise, well done buddy, thanks and keep it up. Suscribed!
Thank you for yet another great video. Really grateful for your content
Awesome solution!
Amazing video as always dude ! keep going :))) helping me alot
SRP is only the first step down the road, if you want to become a better developer it's completely worth it to take some time to learn all the principles of SOLID and understand how to apply it efficiently into your projects. Great job with the explanation, maybe you could try the Open/Closed Principle next? Thanks.
Really helpful content. Keep it up.❤
Thanks for that, just wish all applications was that simple. the one I just took over at work is a nightmare... looks nothing like yours :) Keep up the excellent work!
I know the feeling, I also had to to take over a really bad application once, but slowly we made it look more like this
Thanks, man. Want more videos of design patterns in react 😊
they're coming
Thanks so much for the explanation Sir
very well explained. awesome
great content!
Amazing content, thank you so much!
love it! ❤
Thank you for this video. Your code is really great! It is really important to teach this idea! The value of it is huge and is really important to follow this design principle. However!
You cannot apply SOLID to react directly. SOLID was made for OOP.
You also violate this rule in your previous video if you use this principle as it was described in SOLID. Single responsibility principle is also not single feature principle. It says - you should have ONE REASON to change. It says nothing about “it does one thing”!!! This is important!
I would suggest to never use S in connection to the SOLID in react.
In is even more to U in CUPID principles!
Hi, well explained mate! I'm wondering if you have also a more advanced example where you do CRUD (refetching data after creating a new item for example).
Not yet, but I will!
Clean code, amazing🚀💯
Thanks your effort!
Thank you for this video.
Nice content and topic to learn ❤
very clean
Awesome and clear explanations! I was curious about exports. Here u are using default exports but I see a lot of codebases use named exports. When would u choose one over the other?
They're both fine, I'm just used to default exports personally
@cosdensolutions In my experience named exports are easier to refactor cause the import name will change but with default, it can leave the old one which can be confusing and it will not even error
Very well done
Great tutorial
Would it be better if we move the conditional logic for showing loading or error or products inside the extracted components?
So the productspage will have no conditionals
Nope, it's the responsibility of the products page to decide it wants to show something on loading. The loading component only has the responsibility to show loading UI
Well Explained this help me alot to become a good developer, I have a question the same principle should follow in nextjs?
yes definitely
TY From Colombia
I would also pass the loading, and error props inside of these components and would do the checking inside of them. But that is a matter of taste. Anyway, things shown in the video distinguish juniors from more experienced guys.
hank you for this video
Thank you so much for this content! I wonder how you would define the layout of the several components in the ProductPage? Inside the component or would you put it somewhere separately?
Excellent
Would an higher order component make sense in order to manage the loading, error and display component since on a single page you can have multiple request for different resource ?
Excellent. thanks
Amazing, thanks 👍🏽👍🏽⚡⚡⚡⚡
thanks for this great video, can you talk about how we can write tests and do automated testing for react code?
I have a video on cypress! But will make more
thanks@@cosdensolutions
Thanks, man
I feel like you shouldn't be moving things around based on the single responsibility principal, The code at 9:00 was probably the best version of this code. You can clearly tell the output of the UI based on state and you don't have to navigate to different components that only do one thing resulting in you trying to keep multiple pieces in your head, Things living in one place makes it easier to understand and debug (big components are not inherently bad). You should be moving things into their own components based on re-usability and functionality. You would want a loading and error component not because they should only have one responsibility but rather because you want to reuse them several times in your app. And you might want to move the product UI into it's own component if you needed some logic to run per component.
What vscode extensions / configurations do you use to the have missing import indication in the code (red underline under what is missing) and when you click on it - it adds the import automatically? (As you do in minute 06:52 in the video)
Thanks :)
Have a whole video on my vscode setup!
Is it possible that error state or loading state could render together? Sometimes I need to dig deeper in React Query to know when error is reset.
any recommendation for advanced react like books, online websits, etc
Greate video!
Can you explain in the same way rest of SOLID princeples?)
"Great content."
Thank you for the video. Just a small question, what's the structure of unit tests for this example?
depends on what you want to unit test, I usually wouldn't unit test any of these components. I would only unit test UI components and components that are designed to be re-used across many places. In that case I'd colocate the unit test file with the component and write all the tests there.
I do most of my testing with e2e integration tests generally
This is great but can you do it on a 'real' application? Bit more complex?
Yeah, building a whole project in my upcoming course where we do all of this globally and more design patterns
@@cosdensolutions Excellent. Thanks! I love your content, it's been really helpful
@@cosdensolutions Excellent. Thanks! I love your content, it's been really helpful
can you do a video on composition pattern with a more real world apporach instead of a simple component showing a message that is shown on the various videos about composition pattern?
you mean component composition? i.e. Select, Select.Option, etc?
@@cosdensolutions yes!
Can you do video for all SOLID Principles applied to react application
Thanks
I should ask you, is it good to just check for products(array) in this way? Because empty array will also return true, I'm usually checks for !!pruducts?.length for that. Am I doing it wrong?)
yeah it's fine, if it's an empty array it will render the ProductList but no products will show. It depends on how you want to structure it
@@cosdensolutions yeah, that's true, but there will be empty div inside html, this is not good IMHO
It’s make really hard to debug if nested component there without typescript 😅
everything is harder to debug without typescript 😁
Is single responsibility principle and modularity both are same ?
In case I need to implement the "enabled" prop for useQuery, how can I do that? Is it enough to pass the 'enabled' prop and simply include it in the useQuery?
you don't need to even include it in the useQuery, just pass it
Should we use isError or error in react query?
both, depending on what you need
Same for next js projects ?
yeah, just no hooks or state in server components but same principles apply
@@cosdensolutions Thanks i made some changes in my project `import { Notes } from "@prisma/client";
import SingleWobbleBadge from "@/components/Dashboard/Home/SingleWobbleBadge";
import SingleWobbleDescription from "@/components/Dashboard/Home/SingleWobbleDescription";
import SingleWobbleImage from "@/components/Dashboard/Home/SingleWobbleImage";
import SingleWobbleTitle from "@/components/Dashboard/Home/SingleWobbleTitle";
interface SingleWobbleProps {
wobble: Notes;
}
export default function SingleWobble({ wobble }: SingleWobbleProps) {
const { category, createdAt, description, imageUrl, title } = wobble;
return (
);
}
` what do you think earlier i am rendering all in same component
So, do you mean that, if I have 100 pages, I should create 100 custom hooks just to fetch data from API? What about DRY?
Why we can’t just create 1 universal hook and use it anywhere?
Well yeah, if you have pages, users, posts, comments, and 100 more entities you should make a hook for each. Although you won't in practice.
If you have 100 user pages, one hook is what you need
You may have 100 pages but also your queries wont be much different. So you can implement an universal-like hook for 'Users' which requires the optional query params (like createdAt-updatedAt-roleId etc.). In every single page you can customise your query.
do you have typescript tutorial?
will soon post a JSX to TSX video!
@@cosdensolutions thank you!
The Approach is Good Until If you need to Fetch The Product based on Pagination Data Definitely you must place your fetching logics inside the components that's the better way we can't pass the pagination values to hooks everytime right ?
I usually hold the fetching logic in the page component and the ProductList component can just take a callback whenever it reached the end of the list to fetch more products
sir, could you put results instead of only code on videos? anyway I like ur videos
I'm in my 20s learning to be a programmer/coding, is it too late or not? I'm doubtful about my current age of 🙂
you're way early
I love u bro
Keep up
Great content, can you please share the source-code?
This is good, but the single responsibility principle doesn't necessarily mean everything should do just one thing. It could be things that are closely related as well.
I prefer the product-list should just be part of the page component because the logic won't change or grow overtime. The entire logic is basically a loop and i feel that's too small to be extracted.
So all of my videos are kept super simple right? It will never be just that amount of code. In real projects it's often way more so this pattern applies. Sure if it's a personal small project, you can get away with putting everything in one main component, but I'm not teaching you to build simple projects
I mean you are kinda right but he's teaching how to write code in the best way possible for scaling and managing apps
make a video on zod.
Very informative video indeed however i don't think this was some sophisticated example. Would highly appraciate some more complicated examples of solid. Anyway, thanks for posting!
I mean, this is for beginners mostly so I keep it simple, but for what it's worth, most of your components should look this simple even in a big app
👍
You'd think experienced devs would use snippets. Not typing out: export default function... everytime 😂
Ok so I will comment on this. I have snippets, however I just made the change from arrow functions to declaring them the old school way and I didn't get to the snippets yet lol. But it is fixed in a couple of videos haha
Avoid impure functions as we can this is the SRP
Passing objects to components is bad for performance, better to pass primatives
instead of theory we need how we can do !!! it
The SRP does not mean doing one thing
what does single mean tho
I do most of what you're suggesting here. But, I would have suggested that unless your ui components need to be reused, it is actually easier to keep them in the safe file.
If you're extracting UI components to separate files and they are not reused anywhere else. That's just silly. And actually harder to understand imo.
It's not silly. I'm teaching how to build complex apps, and in complex apps, you'll always re-use these components so defaulting to this pattern makes sense
Hi, we need a playlist for different design pattern implementations in react 🙏🏻
how i can test this components. and is it necessary to make tests for all the components ?
I honestly mostly only do e2e tests of the whole app, and not individual components
Can I connect with you on social media accounts to see timeline about your latest videos ,twitter ,insta or any other etc...
I'm not on twitter, but you can check me out here, on Instagram, or TikTok!
@@cosdensolutions Got it !
my team mates doesn't follow even half of this. It is so hard to go through the project. i wish they watch this video 😂
send it to them