🌀 Why Suspense matters, a short thread

Migrating jQuery rendering logic to React helped me solve UI inconsistencies. A whole class of bugs when imperative mutations to the DOM got out of sync with the underlying app state were gone. Instead of issuing commands like appendChild/removeChild, I described a consistent UI.

When I say

if (condition) {
return <A />
} else {
return <B />
}

I can be confident the UI is consistent with my state. React guarantees it. If condition is true, I'll see A, otherwise I'll see B. I won't see something broken in between. That's the whole point.

However, introducing data fetching (or any asynchronous work) breaks this consistency! If children of <A> each fetch some data (e.g. based on a route param), and that route param changes, they can be inconsistent with each other. Asynchronous data may arrive in different order.

Why is this happening? Because we’re “issuing commands” again! Instead of appendChild()/removeChild(), we now do fetch() and setState() based on that. Or something that essentially boils down to it. As soon as we add this, our UI is no longer guaranteed to be consistent.

Can we solve this somehow? For sure. I mean, people *did* write async apps for decades by now so it’s not like we don’t have solutions. They involve adding something on top (e.g. a global cache or a state machine or some kind of coordinator).

But we did lose an important property of the system. We used to have a guarantee that if we pass a prop down the tree, we're only ever going to see UI that matches this prop value. But we lost this guarantee by introducing asynchronous data fetching. We're back in jQuery days.

This is what Suspense solves. Suspense guarantees the UI you see is always consistent. Instead of "fetching and setting state", we *read* asynchronous data as if it was there. React takes care of waiting for the data to arrive, and only showing consistent results on the screen.

Of course, always waiting for *all* data to arrive would be unfortunate. It would be too slow!

if (condition) {
return <A /> // what if something inside takes too long
} else {
return <B />
}

So do we sacrifice consistency? No.

Instead of sacrificing consistency, we add a new primitive.

function A() {
<div>
<h1>Show me immediately</h1>
<Suspense fallback={<Spinner />}>
<ThisTakesTooLong />
</Suspense>
</div>
}

It lets React "cut off" slow parts in order to stay consistent.

That’s what Suspense is really all about. It’s about ensuring UI is able to always stay consistent despite some parts of it being asynchronous. Once you go all-in on this paradigm, you’ll discover interesting implications. I’ll talk about them some time later.

I should mention here that using Suspense for anything other than code splitting is still experimental 🙂 I’m sharing this to explain where we’re going and why. Not something you need to learn or use today (unless you live on the very edge or want to make your own library).