10 Common Mistakes to Avoid in React Development
React has become a cornerstone in modern web development, but like any powerful tool, i...
For further actions, you may consider blocking this person and/or reporting abuse
What is the need or purpose of "container components" when we can keep state and logic in Context, custom hooks or a state management library?
Thank you for your insightful question! While it's true that we can manage state and logic using Context, custom hooks, or state management libraries, 'container components' are a design pattern that helps with the separation of concerns.
Container components typically handle the data-fetching, state management, and business logic, while presentational components focus on rendering UI. This separation enhances code organization and maintainability, making it easier to understand and manage complex applications.
I'm sorry, but I still don't see the usage of container components as opposed to a custom hook. Let's say you make a widget named Widget, you can make a hook named useWidget containing all the logic, state and data fetching. So you still have separation of concerns, but without the extra container component.
Not only that, but with custom hooks you can also make a mock hook useMockWidget, that you can use when testing the GUI aspects of the Widget, without invoking network calls, etc.
<Widget {...useWidget()} /><Widget {...useMockWidget()} />So you get the exact same separation of concerns you are talking about, but with added benefits.
All in all, using container components seems like a rather dated design pattern, after the introduction of hooks.
It's a valid point that custom hooks, especially with the introduction of hooks in React, provide a powerful way to encapsulate logic and achieve separation of concerns. Your example of using useWidget and useMockWidget for testing is a clever and effective approach.
The choice between using container components and custom hooks often comes down to personal preference, project requirements, and team workflows. While custom hooks are indeed a more modern and concise pattern, some developers and teams still find value in the explicit separation that container components offer, particularly in larger applications or those with more complex state management needs.
It's great to see different approaches to achieving clean architecture in React projects. If container components work well for your use case, that's fantastic! The React ecosystem is diverse, and the beauty lies in choosing the patterns and techniques that best fit the specific context of your project.
I hope it will be helpful.
"some developers and teams still find value in the explicit separation that container components offer,"
Could you indulge me, in what way is container components more explicit than hooks?
I appreciate your curiosity! When I mentioned 'explicit separation` I was referring to the physical organization of concerns in different files or components. With container components, there's a clear distinction between components that handle state management, data fetching, and business logic (containers) and components that focus on rendering UI (presentational components).
While custom hooks also achieve a separation of concerns, some developers find that container components provide a more visual and structured way of organizing this separation. In a large codebase, having a dedicated folder or directory for container components can make it easier for developers to quickly identify where state and logic are managed..
I still don't understand how "container components" is any different from custom hooks in this regard: Custom hooks can also be inside their own files, and be located inside dedicated folders. There simply is nothing about container components thats makes it more visual or structural than custom hooks. Why do you keep repeating these claims?
I appreciate your diligence in seeking clarification. I want to emphasize that the distinction between container components and custom hooks isn't about technical capabilities but more about the mental model and preferences of developers and teams.
Container components, traditionally associated with class components and higher-order components (HOCs), were often explicitly created to manage state and logic. In contrast, custom hooks, introduced with the advent of functional components and hooks, offer a more concise and composable way to encapsulate and share logic.
While both can be organized in files and folders, some developers find that container components, due to their historical association with state management, offer a more recognizable and explicit separation in the codebase. The mental model of having specific components dedicated to managing state and logic can be easier for some developers to grasp.
However, I completely acknowledge that custom hooks, when organized effectively, can achieve the same level of clarity and separation. It all comes down to personal preference, team workflows, and the particular dynamics of the project.🫡🫡
10 is somewhat ironic since class components are no longer a best practice since React 16.8
Yes, You're absolutely right that React has shifted towards functional components and hooks since React 16.8. The mention of class components in point 10 is indeed a bit ironic considering the current best practices. It highlights the importance of staying up-to-date with the evolving React ecosystem. Thank you for pointing that out!
Absolure agree with your arguments, thank you.
Your welcome brother I'm glad you found the arguments convincing. 💖