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.
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 ?
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
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
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?
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!
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
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? 🤔
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. :)
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 ?
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?
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 ?
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
