DEV Community


Posted on

Is it true that components in a ReactJS app should be divided into container components and presentational components?

I guess it is "you don't have to do that", but is it actually good or best practice to actually do that? And if that's the case, how should that be done?

Top comments (5)

sargalias profile image
Spyros Argalias • Edited

As you said, it is completely optional.

There are two reasons why you may want to separate into containers and presentational components:

  1. You can reuse either independently of the other.
  2. Apply the single responsibility principle (code is much easier and safer to work with).

Answer: Separate them if you want the benefits or if you just feel like it. Otherwise there is no reason to. Personally, I lean towards separating them.

In more detail:

Reuse components

If a view is dumb, it can be reused anywhere else in the codebase. You can even put it in an NPM package and use it in other codebases.

One example for this may be a different view for blog posts. Maybe you use the same container, but depending on user preferences or something you can have two different views for the blog posts.

Same with "container logic" (things like getting data and such). Using custom react hooks, you can put logic in there and import them in multiple different containers. This allows you to reuse logic.

For example you may have a single view for blog posts, but perhaps have two different ways you can obtain data for blog posts. Two different containers, which both use the same view.

Single responsibility principle

If logic and views are bundled together, then when modifying either one you could break the other. Also you are working with more code, so there is more to read and understand before you can change anything.

Separating them improves this.

seanmclem profile image
Seanmclem • Edited

One of the original articles that really popularized this idea, by Dan Abramov of react, has since been updated to specifically say that this pattern may actually not be as ideal as originally thought . See here “Presentational and Container Components” by Dan Abramov

And this tweet:

It's really up to preference and situation.

alidhuniya profile image
Ali Hussain Dhuniya

so far what I understood from Dan Ambrov article is that hooks replace these design components pattern. In react hooks we have both view and logic separated in one functional component. If you're not using hooks then sure this design patterns helps especially in bigger project. container component separate logic from jsx like if your component have state,lifecycle, logic while view compoenent is to show props and information that's it and don't have any state,life-cycle

marcin_codes profile image

To be true is approach is a little bit outdated when you are using hooks. Introducing hooks was breaking this rule as hooks are our "containers".

In old approach we separate concerns in this way:

// LoremContainer.js

class LoremContainer extends PureComponent {
 componentDidMount() {
  // perform redux actions

 render () {
  return <LoremComponent {...this.props} />

export default connect(reduxProps, reduxActions)(LoremContainer)

// LoremComponent.js
class LoremComponent extends PureComponent {
 render () {
  // component markup

Now when we are using hooks we are using something like:

// LoremComponent.js
const LoremComponent = () => {
 const { props, actions } = useRedux(reduxProps, reduxActions)

 return (
  // component markup

// useRedux.js
const useRedux = (props, actions) => {
 // perform redux bindings

return { props, actions }

We replace container-component technique in favor of using hooks but we still use separating concerns

sunflower profile image
sunflowerseed • Edited

in the past (without hooks), isn't it true that we can also get by if we use connect and just directly connect to LoremComponent? In the past we didn't have to use a container... but I guess if it is like a component that has 3 other components, then it makes sense to have a container...

but even so... the container can just be a presentational container... and contain 3 stateful components...

or maybe it the past, it means, to always use stateful components (to be container components), and purely non-stateful component (to be presentational components)...