With the arrival of hooks in React, there are now two different patterns for separating business logic from UI logic. The traditional pattern for doing this was to use what are called container components. The more recent pattern is to use hooks. Hooks can accomplish the same goal as container components as we'll see below.

What is a container component?

A container is a React component that has the single responsibility of passing data or state to its children. This data or state is usually fetched asynchronously.

Container components handle asynchronous actions and manage application-level UI state. Container components do not usually have any custom CSS that belongs to them, since they mostly just relay data or state to presentation components, or other containers.

What are hooks?

In 2018, React introduced hooks. Hooks are special functions that start with use. Hooks allow us to "hook into" React features like state.

One benefit of hooks is that they provide us with a way to organize business logic and make that business logic reusable between React components. This benefit is exactly the goal of container components.

Hooks can handle asynchronous actions and manage application-level UI state. Hooks don't have any custom CSS that belongs to them. Rather than relaying data to presentation or view components, hooks are used directly within them to make data accessible to them. Therefore, hooks can replace the need for container components.

With the container pattern, container components are usually placed in a containers folder, while presentation components are placed in a components folder. With React hooks, it's quite similar. Hooks are usually kept in a hooks folder, while presentation components are placed in a components folder.

With both patterns, there should always be an effort to keep the generic presentation components generic. Components such as Button, Modal, and Checkbox, would be considered generic and reusable, without any hooks used within them. Instead, hooks would be used in the parent components that make use of these generic components.

Which pattern is better?

The better pattern is the one where presentation or view logic is most separate from the business logic. This is better achieved with hooks. With container components, presentation logic is more likely to leak into them because they are also React components, just like presentation components are.

Also, it's much easier to use multiple hooks within a React component than it is to pass props from multiple containers into one component.

Conclusion

If the React app is small to medium in size, with component hierarchies that aren't too deep or complex, then using hooks over container components for managing business logic is the clear winner.

If the React app is large, with complex component hierarchies and deeply nested presentation components, then using a combination of both patterns can work well. It's fine to have a mix of both patterns living in a large codebase. Hooks can be used alongside container components. You can then choose the pattern that makes the most sense in a case-by-case basis.