what is the responsibility of the container component in react+redux

Question

I am new to react redux, it has a concept of "Container Component", which is the same as the "Container Component" in react, which focus on how things work. In redux, the container component used to access state from store, to avoid passing props down to the too many nested child components .

Below are my questions:

(1) Do container components responsible for orginazing the business logic?

(2) There are many posts, like Where do I put my business logic in a React-Redux application?, it mentioned to put logic to reducor/action creator/thunk and so on, but not talk about container component, do I miss out something essential?

Answer 1

1) No, business logic should be kept in middle-ware, reducers and selectors.

2) Container component is really every component created by connect HOC (everything connected with the store). As said in point 1 it is not a place for business logic.

---

Bigger answer related to Redux architecture

When using Redux the convention of container->presentation components is not really needed. You should focus on direct connecting components with the store. So instead of choosing which components are connected, are containers, and which are not, are presentation ones, you should focus on delivering the needed data directly.

Preferred is to avoid passing props from parent components and use it when no other way is possible. An example of such avoiding passing props is List -> Element components relation. In the approach with container component, the store would be connected to the List(container) and List would pass all the data to every Element(presentation) component. In the approach without container->presentation, you would send to the Element component only id, and Element component would connect to the store, in order to take obligated properties. Therefor sending props is here reduced to the minimum, and because both components are connected to the store, you can not distinguish them on container->presentation.

---

Additional notice about non-redux architecture

If application doesn't have state management tool like redux, then using container->presentation component approach is very reasonable. This is because the business logic stays only in a part of the program, and exactly I mean containers components, and presentation components can be pure and stateless. Thanks container->presentation segmentation an application has clear separation between state modification and state purity.

Answer 2

As a general practise

The container component specifies the data a presentational component should render. The container component also specifies behavior. If the presentational component has any interactivity — like a button — it calls a prop-function given to it by the container component. The container component is the one to dispatch an action to the Redux store. The container component also access the data from the Redux store

A presentational component is a component that just renders HTML. The component's only function is presentational markup. In a Redux-powered app, a presentational component does not interact with the Redux store.

Here are some important points that @DanAbramov had mentioned in this article about Container Component

1. Are concerned with how things work.

2. May contain both presentational and container components** inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.

3. Provide the data and behavior to presentational or other container components.

4. Call Flux actions and provide these as callbacks to the presentational components.

5. Are often stateful, as they tend to serve as data sources.

6. Are usually generated using higher order components such as connect() from React Redux, createContainer() from Relay, or Container.create() from Flux Utils, rather than written by hand.