What I mean is that you're violating standard separation of concerns when you have components that themselves are capable of dispatching network calls and updat

What I mean is that you're violating standard separation of concerns when you have components that themselves are capable of dispatching network calls and updating the state in an async way directly within the components. As a result, those components no longer have an instantaneous view of the universe, and that makes them harder to test, harder to reason about as isolated units of abstraction, and so on. > Every possible API request also exists on its own outside of anything React That's good, but I would take it once step further and disallow any React component from directly invoking those methods. Of course you're always going to need to do something asynchronously when the user clicks a button or what have you. But in my opinion, it's a lot more maintainable to have that just be an event that the component fires, and then have something else listening for that event out-of-band (and then sending the network request / updating the state to say "connecting" or "request failed" and so on). What happens in async land is not really a pure component's business. (I know I'm definitely out of lock step with the current React ethos on this, so permit a crusty neckbeard his pet gripes.)