Dan wrote a couple great answers on SO that discuss why async behavior in Redux is normally done via middleware such as `redux-thunk` and `redux-saga` - see htt

Dan wrote a couple great answers on SO that discuss why async behavior in Redux is normally done via middleware such as `redux-thunk` and `redux-saga` - see http://stackoverflow.com/a/35415559/62937 http://stackoverflow.com/a/35415559/62937 and http://stackoverflow.com/a/34599594/62937 http://stackoverflow.com/a/34599594/62937 . As a short version: you _can_ put your async logic right into components, but it's nicer to move that logic outside components for reusability. Middleware have access to `dispatch` and `getState`, so they act as a loophole that enables you to perform async work and then interact with the store. My own take is that `redux-thunk` is sort of the "bare minimum" approach to async behavior, as it allows you to do stuff with promises and async functions, or complex synchronous logic. Sagas are useful for complex async workflows, and there's also some popular observable-based side effects addons as well. Ultimately, the approach you use is up to you. If you'd like more info on what good Redux code structure looks like, you may want to read through the "Redux Architecture" and "Redux Techniques" section of my React/Redux links list at https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master... . Also happy to answer any questions you might have.