I'm a Redux maintainer (as is Tim Dorr, who submitted the post).
Use of promises with dispatching is, as far as I can see, not relevant to this particular discussion. It seems that the caching aspect is up to you - the important thing is that if a component decides it needs to wait for data before it resumes rendering, it needs to throw a promise.
What _is_ relevant is figuring out how to synchronize dispatched actions that cause updates to the Redux store with React possibly pausing a given component tree re-render cycle, applying a different update, and then resuming the rest of the original update. We've had some initial discussions, and are still trying to grasp what the impacts are here.
Ultimately, it's possible there will be internal changes to the React-Redux library - we just don't know what those changes will be yet. But, if there are, we'll do our best to keep the public API stable.
Use of promises with dispatching is, as far as I can see, not relevant to this particular discussion. It seems that the caching aspect is up to you - the important thing is that if a component decides it needs to wait for data before it resumes rendering, it needs to throw a promise.
What _is_ relevant is figuring out how to synchronize dispatched actions that cause updates to the Redux store with React possibly pausing a given component tree re-render cycle, applying a different update, and then resuming the rest of the original update. We've had some initial discussions, and are still trying to grasp what the impacts are here.
Ultimately, it's possible there will be internal changes to the React-Redux library - we just don't know what those changes will be yet. But, if there are, we'll do our best to keep the public API stable.