React _is_ only a view library. It shouldn't have any thing to do with things like Ajax - that's part of what makes it simple to work with l. It does one thing and does it well.
It doesn't even seem to be the responsibility of Redux, which more so is consider with prescribing _how_ data and actions flow through your system, not how exactly those calls touch the outside world.
I don't like employing the phrase "separation of concerns" that often / without serious thought, but this is seems to be a valid use case for it. Presentation components shouldn't care about how fetches data, they should ideally just be a function of their props. Even container components should only care about what data they are accessing, not how it comes to be in the data store.
What you're asking for could just be a plain JS library - when you ask for certain routes in your app, fetch some data. When it comes in, handle all those edge cases you describe. Update the data store. When that happens, we're finally back in Redux land. It doesn't care about how you fetch your data, all it cares about is _that_ you touched it at all.
When I say comes with React, I mean like immutability-helpers or Redux or the concept of higher order components, or the idea of css modules. I think it would be a good, optional, companion.
(And the following is not directed against you, but a comment in general: I often feel that many people on HN never heard about the principle of charity, assume I don't know what I'm talking about, and when there are two ways to interpret what I say, assume the least sensible interpretation. This makes commenting quite stressful sometimes, and you feel like having to hedge every comment... Like I tried in the first sentence.)
I do think that there is some kind of implicit framework living within a smart combination React, Redux, and Immutable.js that combined with something like Uncle Bob's clean architecture could probably become a standard within the React world. My company is maybe 50% of the way there towards such a thing, and it really is a pleasure to work with.
This relates to the discussion I've been trying to have on potential abstraction layers that could be built on top of Redux to make it easier for some people to learn and work with [0]. There ARE a large number of existing libraries out there for things like fetching and managing normalized entities [1], as well as some more extensive frameworks like `dva` [2].
I'd be interested in hearing more details about what your company has put together. If you get a chance, please drop by the Reactiflux chat channels [3] and ping me.
I don't like employing the phrase "separation of concerns" that often / without serious thought, but this is seems to be a valid use case for it. Presentation components shouldn't care about how fetches data, they should ideally just be a function of their props. Even container components should only care about what data they are accessing, not how it comes to be in the data store.
What you're asking for could just be a plain JS library - when you ask for certain routes in your app, fetch some data. When it comes in, handle all those edge cases you describe. Update the data store. When that happens, we're finally back in Redux land. It doesn't care about how you fetch your data, all it cares about is _that_ you touched it at all.