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.
Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
21–30 of 66 posts
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#22This 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.
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?
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#23Earlier quoted context omitted.
But only when passed to HTML elements I hope. Because say I have my own type of the shape `{ then(): Whatever }` and try to pass that as a prop to one of my components I don't want React to invoke that function.
It's not about passing props - the "thenable" detection comes into play if you throw a promise (or something shaped like a promise) from within `render()`.
Wait, can render functions now throw, legally?
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#24This 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.
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?
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.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#25Earlier quoted context omitted.
It's not about passing props - the "thenable" detection comes into play if you throw a promise (or something shaped like a promise) from within `render()`.
Wait, can render functions now throw, legally?
Yup. This builds on error boundaries and componentDidCatch: https://reactjs.org/blog/2017/07/26/error-handling-in-react-...
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#26Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#27Maybe a dumb question or wrong forum. But how do you start using latest React in a project?
Npm has alpha versions react@16.4.0-alpha.0911da3 and react-dom@16.4.0-alpha.0911da3 you can experiment with.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#28So glad someone captured this talk! At the 15 minute mark, he introduces a new paradigm for asynchronous IO within render functions; see a screenshot here: https://www.dropbox.com/s/wybqgtftuyqipk8/Screenshot%202018-... . This is groundbreaking, to say the least, as previously this needed to be done by adding higher-order components to inject the result of the fetch as a prop at some higher level; now, it's as simple…
Is the cache global?
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#29I’m pretty excited to see how the api could interop with some new native features of js, like for ex async class functions are now possible and I bet a setup like this could remove a lot of IO overhead in the future
class Test {
async render() {}
}
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#30So glad someone captured this talk! At the 15 minute mark, he introduces a new paradigm for asynchronous IO within render functions; see a screenshot here: https://www.dropbox.com/s/wybqgtftuyqipk8/Screenshot%202018-... . This is groundbreaking, to say the least, as previously this needed to be done by adding higher-order components to inject the result of the fetch as a prop at some higher level; now, it's as simple…
Is the cache global?
It's up to you. I intentionally kept moving parts to the minimum in my demo, but here's the real thing I was using behind the scenes: https://github.com/facebook/react/tree/master/packages/simpl.... So in that sense it's not global, you can create as many as you like and then isolate them (e.g. per subtree).
The `simple-cache-provider` is just a reference implementation though. It's somewhat naïve, e.g. it doesn't have invalidation strategy and just lets you replace the whole cache with a new one if you want to invalidate.
We'll publish more details on lower level API and how to write your own cache in the future.