React-Redux容器组件职责及业务逻辑归属技术问询

Hey there! Great questions—let’s break this down clearly since container components can feel a bit ambiguous when you’re starting out with React-Redux.

1. Do container components handle business logic? #

Short answer: No, they shouldn’t.

Container components (often called "connected components" in modern React-Redux, thanks to connect() or hooks like useSelector/useDispatch) have a single, focused job: acting as a bridge between your Redux store and your UI (presentational) components. Their core responsibilities are:

• Mapping specific pieces of Redux state to props for UI components via mapStateToProps or useSelector
• Wrapping action creators into dispatch-ready props via mapDispatchToProps or useDispatch

Business logic—like API calls, data validation, complex data transformations, or rules for state updates—doesn’t belong here. If you stuff this kind of logic into container components, you’ll end up with bloated, hard-to-reuse code. For example, if two different UI components need to fetch the same user data, you’d have to duplicate that API logic in both containers instead of reusing a single action creator.

2. Why do articles focus on reducers/action creators/thunks instead of container components? #

You’re not missing anything—this is intentional, and aligns with Redux’s core design philosophy of separating state management logic from UI rendering.

Here’s how the typical分工 works:

• Action creators/thunks/sagas: Handle asynchronous logic (like API calls) and prepare data to send to the store. Thunks, for example, let you write async code that dispatches actions once the async operation finishes.
• Reducers: Define how the state changes in response to actions—this is where you encode business rules for updating state (e.g., "only mark an order as completed if payment is confirmed").
• Container components: Simply pass the current state from the store and action dispatchers down to your presentational components. They don’t care how the state is updated or what the business rules are—they just handle the connection between store and UI.

Think of container components as the "glue" that holds your Redux logic and UI together, not the place where the logic lives. This separation makes your code more testable (you can validate business logic without rendering UI) and easier to maintain (changing a business rule only requires updating the relevant action creator or reducer, not every container that uses it).

内容的提问来源于stack exchange，提问作者Ron Smith