Redux reducers don't manage the state of the view, but of the app. Redux state is the "M" in MVC; Redux action creators are the "C".
The view's job is to display the current state, translating it into something presentable. Views call action creators to request changes to the state, or to report events that action creators should use to make changes to the state. Action creators implement business logic.
Edit: To be clear, this doesn't mean you have to do logic in action creators. You can keep action creators "pure" (not thunked), and instead have a business logic layer that mediated between view and action dispatching. Saga is one way of doing this. Redux doesn't mandate anything specific.
Reducers are a way to serialize the state so that all state transitions happen as a strictly sequential chain of modifications. This is done to prevent the spaghetti mess you get when (as in traditional MVC systems like Cocoa) everyone is allowed modify the state directly, and views merely observe state. By flowing state through a single bottleneck, there's only one moment when the UI needs to transition to a new state. With observation-based systems, it's completely unpredictable and certainly not reversible.
React components do of course also have something called "state", but you have to think of that as the UI state, i.e. things needed to manage the view, such as whether a dropdown is open or what the current text of an input is.
There's also the temptation to put UI-specific state in Redux. This is perfectly normal, and even desirable. The "M" in MVC is not some abstract ivory-tower notion that there exists some world state that's entirely independent of the view. The state serves the view; whatever the view needs must be provided by the state.
The view's job is to display the current state, translating it into something presentable. Views call action creators to request changes to the state, or to report events that action creators should use to make changes to the state. Action creators implement business logic.
Edit: To be clear, this doesn't mean you have to do logic in action creators. You can keep action creators "pure" (not thunked), and instead have a business logic layer that mediated between view and action dispatching. Saga is one way of doing this. Redux doesn't mandate anything specific.
Reducers are a way to serialize the state so that all state transitions happen as a strictly sequential chain of modifications. This is done to prevent the spaghetti mess you get when (as in traditional MVC systems like Cocoa) everyone is allowed modify the state directly, and views merely observe state. By flowing state through a single bottleneck, there's only one moment when the UI needs to transition to a new state. With observation-based systems, it's completely unpredictable and certainly not reversible.
React components do of course also have something called "state", but you have to think of that as the UI state, i.e. things needed to manage the view, such as whether a dropdown is open or what the current text of an input is.
There's also the temptation to put UI-specific state in Redux. This is perfectly normal, and even desirable. The "M" in MVC is not some abstract ivory-tower notion that there exists some world state that's entirely independent of the view. The state serves the view; whatever the view needs must be provided by the state.