Take a note that when you use the custom hook with useEffect in more than one file, the useEffect will run more than once, so keep one custom hook for every layout/component (let say one for user list, one for user details). If not, just move the useEffect outside the custom hook
This is a good start, but in general I would prefer to abstract fetch away a step further than hooks or components and you also need to handle loading and error states with your async calls. As an example, create a UserProfileRepository and UserProfileService classes which have functions for CRUD on UserProfiles. Use the singleton pattern on these classes and keep them in a context where it is required in the app.
I struggle with choosing between fetching on the page and passing down or fetching in the components as well. I think it makes sense for both, but it is better if you separate concerns and fetch from the page. This way, your component only cares about rendering and doesn't deal with how it gets the data. It makes those components simpler as well and probably easier to test
because ProfileData is only responsible for rendering, not fetching. Also, if you want to show profileData but with different filters or page sizes, adding that inside will be a mess. The way I did it, the parent decides that and just gives it to ProfileData to take over. It's simpler
@@cosdensolutions but in case I need to use the data of filters or page sizes from ProfileData to refresh profiledata, should I use a callback to left it to ProfilePage or move fetching into ProfileData component?
I'm truly captivated by your content and watch it daily during my free time. Please continue to create great content. Regarding this video lesson, I have a question: How do you plan to organize the subcomponent or child component files when you break down a large page into smaller components?
Thank you for the kind words! You follow the single responsibility principle. Each component only does one thing until you've run out of things to do. So page component renders page and all features on page, then each feature gets its own component for the feature, and each one of those uses other components that make up the feature. There isn't really a strict rule as to how exactly, but rather it all depends on the features themselves and how logical it is to separate them. But generally following the SRP is a great way
A beginner here, this approach definitely makes our code more clean. but my doubt is, say if we are building a little advanced/complex project, the same approach makes too many folders and files ?
Look up screaming architecture. Keep your code modular and it doesn't matter how many folders and files you have (when it becomes insanely complex then you need microservices or microfrontends, but that's not the common case, you usually use a monolith, i. e., a single application doing everything, instead of lots of independent services with a single purpose). It's way better than having huge files doing lots of things. For example, if you're looking for changing how the profile data is displayed, would you be looking for ProfilePage or ProfileData? The second one seems more intuitive, because it's straightforward. That's the goal. Make everything as intuitive as possible, so navigating through the codebase is a breeze.
if you export as a default then you can import it at any name // Exporting a component with export default const MyComponent = () => { // Component implementation }; export default MyComponent; import MyComponent from './MyComponent'; without export default // Exporting a component with named export export const MyComponent = () => { // Component implementation }; // Importing the component import { MyComponent } from './MyComponent'; you need to call with same name
Great video Cosden! It's definitely something I've been looking into lately cause I don't like long complex components that I have to edit/create. I was just curious about something though, i noticed in your imports you have an @ symbol at the beginning and was wondering how that was setup and if there is an advantage to it? Thanks!
Thank you for another great video! I've been learning a lot here! One question: Why do you prefer to use type instead of interface in the props definition? 🤔
Can't we just use the useFetchProfile hook inside the ProfileData component itself instead of passing profileData as props from ProfilePage component? Is it a bad practice? What complications could have with that approach?
Thank you for this amazing video it's really helpful and it has increased my productivity, but can I use utils folder, as you said and just add reusable function for similar work ?
Why would you use this Layout component on every page like this ? Just pass it to the index route and thats it. Overall I see this is "basic 101" and way far from Sr. react code. And I personally think this is not the best way to describe "custom hooks" as it should be. This profile code belongs to the Service layer. Don't get me wrong, I'm not here to argue, just have some questions over all. :)
Hey Man , really nice video ! I was wondering if I could help you with Viral Content ideas in your niche , Script , editing , thumbnail , SEO , Growth and analysis , Leads and appointments for your business , etc in all to you ! Pls let me know what do you think ?
), errorElement: , children: [ { index: true, element: , }, { path: 'search', element: (... this way all childrens will have layout and no need to import it as wrapper inside page components
I would not agree with the final advice in the video (namely "build a habit of splitting...you will never build messy components") - the pattern you are prescribing for everyone and everything is called 'separation of concerns' and to that I usually say to less experienced devs: start separating when you get concerned. In your case - start extracting functionality when you see that it is reusable (like the layout is in your video, but not the profile fetching - your approach for fetching also has other issues - some commenter mentioned it bellow) but not before that. Otherwise great video (and most of the other videos you made).
Take a note that when you use the custom hook with useEffect in more than one file, the useEffect will run more than once, so keep one custom hook for every layout/component (let say one for user list, one for user details). If not, just move the useEffect outside the custom hook
as a begginer one, im doing this by habbit and i was scared if it was overkill or not. now i feel happy!
This is a good start, but in general I would prefer to abstract fetch away a step further than hooks or components and you also need to handle loading and error states with your async calls.
As an example, create a UserProfileRepository and UserProfileService classes which have functions for CRUD on UserProfiles. Use the singleton pattern on these classes and keep them in a context where it is required in the app.
definitely the best approach for this kind of scenario!
This was Needed 😀 ThankYou, i was having anxiety seeing lots of styling classes in return of every component
mate, i'm enjoying your react content, this is what i need to learn, keep making content
Thanks for explaining the importance of achieving modularity in our code.
Thank's for your content, my brother.
Awesome video.. Really appreciate how you always adhere to SOLID principles in your videos
Great video. Only question I have: why not move the useFetchProfile inside the ProfileData page instead of passing it as a prop?
I struggle with choosing between fetching on the page and passing down or fetching in the components as well. I think it makes sense for both, but it is better if you separate concerns and fetch from the page. This way, your component only cares about rendering and doesn't deal with how it gets the data. It makes those components simpler as well and probably easier to test
because ProfileData is only responsible for rendering, not fetching. Also, if you want to show profileData but with different filters or page sizes, adding that inside will be a mess. The way I did it, the parent decides that and just gives it to ProfileData to take over. It's simpler
@@cosdensolutions Thanks for clarifying!
@@cosdensolutions but in case I need to use the data of filters or page sizes from ProfileData to refresh profiledata, should I use a callback to left it to ProfilePage or move fetching into ProfileData component?
cosden how are u making sidebar in vscode and how u are controlling it please make tutorial
telekinesis
why not having ProfileData component call the useFetchProfile ?
Simple, effective tips that are easy to learn and apply. Thank you for sharing your knowledge!!!!
Perfect timing, just wanted to learn about those :D
I'm truly captivated by your content and watch it daily during my free time. Please continue to create great content. Regarding this video lesson, I have a question: How do you plan to organize the subcomponent or child component files when you break down a large page into smaller components?
Thank you for the kind words! You follow the single responsibility principle. Each component only does one thing until you've run out of things to do. So page component renders page and all features on page, then each feature gets its own component for the feature, and each one of those uses other components that make up the feature. There isn't really a strict rule as to how exactly, but rather it all depends on the features themselves and how logical it is to separate them. But generally following the SRP is a great way
@@cosdensolutions Great! I had a small doubt and now it's cleared. Thank you for the reply. ☺
A beginner here, this approach definitely makes our code more clean. but my doubt is, say if we are building a little advanced/complex project, the same approach makes too many folders and files ?
Look up screaming architecture. Keep your code modular and it doesn't matter how many folders and files you have (when it becomes insanely complex then you need microservices or microfrontends, but that's not the common case, you usually use a monolith, i. e., a single application doing everything, instead of lots of independent services with a single purpose). It's way better than having huge files doing lots of things. For example, if you're looking for changing how the profile data is displayed, would you be looking for ProfilePage or ProfileData? The second one seems more intuitive, because it's straightforward. That's the goal. Make everything as intuitive as possible, so navigating through the codebase is a breeze.
@carlostalavera4964 thankyou !!
Thank you for the fantastic content!
What is your view on default exports? In my opinion they should only be used in libraries, not in any other code.
if you export as a default then you can import it at any name
// Exporting a component with export default
const MyComponent = () => {
// Component implementation
};
export default MyComponent;
import MyComponent from './MyComponent';
without export default
// Exporting a component with named export
export const MyComponent = () => {
// Component implementation
};
// Importing the component
import { MyComponent } from './MyComponent';
you need to call with same name
Default exports should be banned. They are not adhesive to strong typing and make tree shaking impossible especially when mixed with named export.
Hey, which vs code theme you are using.? Excited to use it for my self also.
Great video Cosden! It's definitely something I've been looking into lately cause I don't like long complex components that I have to edit/create. I was just curious about something though, i noticed in your imports you have an @ symbol at the beginning and was wondering how that was setup and if there is an advantage to it? Thanks!
it's import aliases, the advantage is it makes things cleaner, and if you move things you don't have to always have everything be rewritten
Thanks, ill try this in old prijects to see if i can improvement
I would move static data array upper, from the App component. It’s static, no need to recreate it on every re-render.
What do you think of atomic design and styled components? Only got to the page layout so far, but that seems like a perfect case for that, no?
should I still separate the fetching hook if only one component uses it?
Thank you for another great video! I've been learning a lot here!
One question: Why do you prefer to use type instead of interface in the props definition? 🤔
can you make a video on MVVM architecture with react ?
I have one question. Why you didn't use React.FC or forwardRef in any of your videos. Is it usseles to use?
How about modals or dialogs that are used in one page? Do we handle them all in the parent component?
Such good tutorials.
I think you can use Nuxt and all the layout, structure will be already configured for you out of the box.
is it me or is the audio levels on this video really low. i have my headphones at 50 % and its quite low compared to other videos
Shouldn't the PageLayout.tsx be located in the pages folder, while the 'Profile' file should be in the in components?
great video. its very useful. 🤩
Honest question, are you doing this in the real world app or in your work?
PageLayout -> ProfilePage -> ProfileData -> Children Components (Avatar, PostList, etc)
Can't we just use the useFetchProfile hook inside the ProfileData component itself instead of passing profileData as props from ProfilePage component? Is it a bad practice? What complications could have with that approach?
I mean isn't the children example you gave in the first one just what we do in App.jsx though?
Thank you for this amazing video it's really helpful and it has increased my productivity, but can I use utils folder, as you said and just add reusable function for similar work ?
How to handle authentication on the API
Make a video about Social Login system in react please
Why would you use this Layout component on every page like this ? Just pass it to the index route and thats it. Overall I see this is "basic 101" and way far from Sr. react code. And I personally think this is not the best way to describe "custom hooks" as it should be. This profile code belongs to the Service layer. Don't get me wrong, I'm not here to argue, just have some questions over all. :)
anyone know what allows him to do rjsfc and have the react component with function keyword? i just have rafc and its the arrow funciton i hate it
check out my vscode setup video
why would you use export default function instead of export const?
@@nicus1504 i just like using function better its personal preference
Sir i'm interest of React Project but my english isn't very well. Is there subtitle like in TH-cam?
yes there is!
in a real project , a loading , error is also needed.
Hey Man , really nice video ! I was wondering if I could help you with Viral Content ideas in your niche , Script , editing , thumbnail , SEO , Growth and analysis , Leads and appointments for your business , etc in all to you ! Pls let me know what do you think ?
props with children makes children optional, for layout it needs to be required
export const router = createBrowserRouter([
{
path: '/',
element: (
),
errorElement: ,
children: [
{
index: true,
element: ,
},
{
path: 'search',
element: (...
this way all childrens will have layout and no need to import it as wrapper inside page components
I would not agree with the final advice in the video (namely "build a habit of splitting...you will never build messy components") - the pattern you are prescribing for everyone and everything is called 'separation of concerns' and to that I usually say to less experienced devs: start separating when you get concerned. In your case - start extracting functionality when you see that it is reusable (like the layout is in your video, but not the profile fetching - your approach for fetching also has other issues - some commenter mentioned it bellow) but not before that. Otherwise great video (and most of the other videos you made).
in your video description ,the project react lik is give me 500 web code .
يمزاجك يا كوزدين
Increase your voice please... Its so low.... Thanks for zooming screen
nah I like it because he’s not yelling or doing a “youtuber voice”
His volume level is good,try to check your speaker
If only there was a way to increase the volume of a video??!?
throw your speakers in the trash and get new ones.
Volume is good.