3 ms·

This is pretty amazing, kudos to the React team! Just hope that SSR isn't an afterthought with this feature. That is probably been my only little grouse with th

This is pretty amazing, kudos to the React team! Just hope that SSR isn't an afterthought with this feature. That is probably been my only little grouse with the React team that SSR compatibility is always a 'Not sure, someone should try it' response.

anotherfounder 9y ago
I guess another question I have is how does the React or the Redux team see this playing with Redux. Dispatch returns promises but then the cache is the redux store itself - so would the fetcher read from the store possibly?
- acemarke 9y ago
  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.
oyeanuj 9y ago
Also curious how this would work with SSR? Will the render be considered incomplete until all subtree promises have resolved? If so, that would solve one of the biggest pain points working with SSR + React today. Today, the solution is to have you route level component load data which is far from ideal.
spicyj 9y ago
We aren't sure if we'll have time to build it ourselves (vs finding external contributors to build support and upstream it) but this design should handily address the long-standing requests to wait for async data during SSR. We thought about it.

anotherfounder 9y ago

I guess another question I have is how does the React or the Redux team see this playing with Redux. Dispatch returns promises but then the cache is the redux store itself - so would the fetcher read from the store possibly?

acemarke 9y ago
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.

oyeanuj 9y ago

Also curious how this would work with SSR? Will the render be considered incomplete until all subtree promises have resolved? If so, that would solve one of the biggest pain points working with SSR + React today. Today, the solution is to have you route level component load data which is far from ideal.

spicyj 9y ago

We aren't sure if we'll have time to build it ourselves (vs finding external contributors to build support and upstream it) but this design should handily address the long-standing requests to wait for async data during SSR. We thought about it.