I would recommend against business logic inside components, unless you have dedicated higher order components with focussed responsibilities - but even that is not ideal. See "Caveats with using HOCs for side-effects" here.

Reducers are not ideal either because your logic may involve asynchronous steps.

In flux/redux logic belongs in action creators or sagas. The above answer also compares intelligent action creators with sagas.

I have lately resorted to putting logic in mostly framework independent Manager and Strategy classes with async functions which dispatch actions to communicate the results to the Redux store.

This article is a good read discussing various options, my preference is sagas medium.com/@jeffbski/where-do-i-put-my-business-l…

Don't put business logic in components. You want to keep it separate from the view logic.

Actions and Reducers are also the wrong place. Well, some might fit into a reducer. But as soon as you have async stuff (i.e. API calls) then it makes sense to have a separate layer for business logic.

When I started out, I tried thunks (via redux-thunk) and thought they were great. But over time it seemed like they weren't good enough. I struggled big time until I found Redux-Saga, which literally revolutionized the way I think about and write Redux code.

Check out this redux-saga introductory tutorial. I hope it helps! :)

Into selectors! Then you get async updated data and don't need to store unnecessary things in your reducer / can share the data across components easily if needed later github.com/reactjs/reselect