[badthingfactory]

This is my experience as well. The largest struggle I have with Redux is understanding where things belong. Where do ajax calls go? Should I use redux-thunk? That feels like an anti-pattern to me. Redux-saga is interesting, but it's going to be really tough for unfamiliar devs to understand generators with infinite loops. I also don't feel like writing an infinite loop every time I want to perform a simple fetch. With mobx, shared code goes in a class, it doesn't matter if it's async or not, and observable properties get a decorator.

[acemarke]

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 and 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... . Also happy to answer any questions you might have.