4 ms·

This is not how Suspense works. It doesn't just add loading states to your component, so a new primitive is needed and a polyfill won't do. With Suspense if a c

This is not how Suspense works. It doesn't just add loading states to your component, so a new primitive is needed and a polyfill won't do. With Suspense if a component renders async data, you can simply wait (notice, different from showing a loader) for it to finish. In essence, React has a new primitive where calling setState will try to render the tree, but only flush changes to the DOM once all the components in the tree have finished loading. If you call setState again during this process (the app is still usable while waiting), and changes are to be made on the same portion of the tree that's currently loading async data, then React will simply dismiss the old tree from ever rendering - fixing race conditions in a natural/clever way.

davnicwil 9y ago
Thanks. I've yet to look into the details, but my intuition was that Suspense could be a 'native' solution for synchronous rendering on the server - this is basically the missing feature in React itself that I was talking about needing to polyfill - essentially via a wasteful workaround that requires two server renders to be run instead of one. The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve - what react-frontload does though is gets the same component to also synchronously load that same data (using the same function) on server render. This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together. That's the problem that react-frontload solves - the client side loader thing is up to you to implement, even with react-frontload. What I'm hoping is that it may be possible to go back to writing this stuff manually on certain components, because it'll be simple enough with Suspense - or at least just make the implementation of react-frontload much simpler and carry on using it as syntax sugar (it's quite nice to just define an async data loading function via a HOC, for instance - you obviously wouldn't get that having to hand code lifecycle methods for each component).
- danabramov 9y ago
  Suspense is both for client and server. >The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve The problem Suspense is solving on the client is not straightforward. But you'll need to see my demo (second part of this talk[1]). It's very hard to talk about in abstract without seeing it. The big difference Suspense brings is the ability to wait with the whole state transition until all leaves are ready. Think transitioning between pages (that need data) is as easy as updating state in the parent, and React takes care of “waiting” for the page to be ready before displaying it (or falling back to a placeholder). >This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together Suspense takes care of that, you don’t need to manually collect Promises. [1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...
  - davnicwil 9y ago
    Cool - I will definitely go actually figure out what Suspense does in detail. Thanks for the link! Now you've got me thinking, and you're right. Even in a client-only case, the simple spinner-until-data-loaded pattern works for a solo component just fine, but doesn't at all account for waiting for children, etc, without implicit dependencies between parent and child. If you've got stuff like that going on, then yes this is a pretty complex problem. It does definitely seem like Suspense is going to remove most of the complexity involved in the 'synchronous' server render problem, especially with regards to manual promise collection. This is awesome work :-)

davnicwil 9y ago

Thanks. I've yet to look into the details, but my intuition was that Suspense could be a 'native' solution for synchronous rendering on the server - this is basically the missing feature in React itself that I was talking about needing to polyfill - essentially via a wasteful workaround that requires two server renders to be run instead of one. The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve - what react-frontload does though is gets the same component to also synchronously load that same data (using the same function) on server render. This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together. That's the problem that react-frontload solves - the client side loader thing is up to you to implement, even with react-frontload. What I'm hoping is that it may be possible to go back to writing this stuff manually on certain components, because it'll be simple enough with Suspense - or at least just make the implementation of react-frontload much simpler and carry on using it as syntax sugar (it's quite nice to just define an async data loading function via a HOC, for instance - you obviously wouldn't get that having to hand code lifecycle methods for each component).

danabramov 9y ago
Suspense is both for client and server. >The client side thing of implementing async loading with a loading prop and componentDidMount obviously has to be done 'manually', this is straightforward and not something I'd expect React or even a library to solve The problem Suspense is solving on the client is not straightforward. But you'll need to see my demo (second part of this talk[1]). It's very hard to talk about in abstract without seeing it. The big difference Suspense brings is the ability to wait with the whole state transition until all leaves are ready. Think transitioning between pages (that need data) is as easy as updating state in the parent, and React takes care of “waiting” for the page to be ready before displaying it (or falling back to a placeholder). >This is much more fiddly and is way too much boilerplate to write manually for each component, not to mention that you need some global context to tie all the promises together Suspense takes care of that, you don’t need to manually collect Promises. [1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...
- davnicwil 9y ago
  Cool - I will definitely go actually figure out what Suspense does in detail. Thanks for the link! Now you've got me thinking, and you're right. Even in a client-only case, the simple spinner-until-data-loaded pattern works for a solo component just fine, but doesn't at all account for waiting for children, etc, without implicit dependencies between parent and child. If you've got stuff like that going on, then yes this is a pretty complex problem. It does definitely seem like Suspense is going to remove most of the complexity involved in the 'synchronous' server render problem, especially with regards to manual promise collection. This is awesome work :-)