@BenLesh @AdamRackis @DavidKPiano Yeah those aren’t concerns solved by Suspense. Eg we use Relay for that. Suspense is very much for “reading asynchronous data” from components and coordinating a loading state sequence.
@BenLesh @AdamRackis @DavidKPiano Here are the concerns solved by Suspense:
- Single declarative way to specify loading states decoupled from *what* is loading (GraphQL, REST, JS bundle, images) and where in the tree
- Graceful orchestration of those loading states (control over reveal order, avoiding flicker)
- Single declarative way to specify loading states decoupled from *what* is loading (GraphQL, REST, JS bundle, images) and where in the tree
- Graceful orchestration of those loading states (control over reveal order, avoiding flicker)
@BenLesh @AdamRackis @DavidKPiano On the component level, it does help you avoid async/await mess and race conditions. So it has benefits over “ad hoc data fetching in component”, like manual fetch in lifecycle methods. But as you pointed out, there are indeed other solutions to that.
@BenLesh @AdamRackis @DavidKPiano The reason we’re saying it helps avoid race conditions is not because you can’t do it differently. You can, and probably should! (Eg Relay takes care of that too.)
But the goal is that “simple fetch in componentDidUpdate” is usually buggy but “simple read in render” is not.
But the goal is that “simple fetch in componentDidUpdate” is usually buggy but “simple read in render” is not.
@BenLesh @AdamRackis @DavidKPiano So the point of this isn’t that someone should throw away their Rx or statechart logic. No.
The point is you can integrate them tighter with React to get extra control over rendering.
And even for people who *don’t* use these techniques, a whole class of bugs is still gone.
The point is you can integrate them tighter with React to get extra control over rendering.
And even for people who *don’t* use these techniques, a whole class of bugs is still gone.
@BenLesh @AdamRackis @DavidKPiano Suspense also offers some new capabilities that data sources can take advantage of. For example, a response can gradually “unlock” deeper levels of data as it streams. That’s not new... but with declarative loading states, it means the app can also “unlock” UI in coordinated way.
@BenLesh @AdamRackis @DavidKPiano I like to think of Suspense as a way to find balance between technological and UX extremes. Technologically, streaming data and rendering immediately as it comes is fastest. UX-wise, it would be terrible to see every component load separately and shift layout every few ms.
@BenLesh @AdamRackis @DavidKPiano Suspense lets us choose well-defined boundaries where we’re willing to show loading states. That lets us stream data as it comes (and start rendering immediately) but only show result to the user in places we agreed to, in order we agreed to, and with a frequency that feels good.
@BenLesh @AdamRackis @DavidKPiano And let’s not forget it’s not just about data. Suspense doesn’t care what we’re waiting for. It uses the same mechanism for code, data, and any other async things you need. So you can stream code and data in parallel, and the app can “unlock” deeper loading states as we fetch.
