1 of 28

Suspense for data fetching:

How to fetch

during render

Robert Balicki ◆ ex-Relay team @ Meta

@StatisticsFTW ◆ robert.balicki@gmail.com

@isograph/react-disposable-state

github.com/isographlabs/isograph

Hi folks, my name is Robert Balicki. Until recently, I worked on Relay, the framework for building React apps that consume GraphQL data, at Meta. You can follow me on Twitter at @statisticsftw.

Today, I'll be talking about suspense for data fetching in React apps. That's a big and scary subject 🔸, so we'll focus on one specific aspect of it: 🔸 how to start network requests when a component first renders.

�Sounds easy, right? Just make the darn API call! What could go wrong? A lot, actually. This is one of the toughest things for a data fetching library to get right.��So, in order to understand how a data fetching library can enable this kind of fetching, we'll need to learn about when and under what conditions React will render your components, and especially how Suspense affects that. After all that, it'll still be complicated, but I hope it makes conceptual sense.

And we'll finish this up with a demo of a very simple custom data fetching library that is compatible with suspense.�

This demo will make heavy use of a library of hooks that I wrote — the name of this library is @isograph/react-disposable-state. This library will eventually do much of the heavy lifting of the Isograph framework runtime.

2 of 28

Goals

Make network calls during the render phase
Understand other times to fetch: in an effect and in advance
Understand React and Suspense

3 of 28

Non-goals

Refetching
Caching
Offscreen, hot reloading
Server components, use(...)

4 of 28

Agenda

Comparison of fetching strategies
When does React render components?
Need external cache
@isograph/react-disposable-state
Demo

Okay, so that's what we'll learn, but how exactly will that happen? What are we going to cover today?

🔸First, we'll take about 10 minutes to compare the different ways an app might fetch the data a component needs. It might make the network request in the component and fetch in an effect, it might start the network request in the component but fetch during render, or it might start the network request at an unrelated time, which we call fetching in advance, and passing some prop down to the component that needs the data. This whole comparison is meant to help us understand why we want to even bother supporting fetching during render, which is the toughest of the three to implement, by far.

🔸Then, we'll talk about when and under what circumstances does React render components, which is to say, when does it call their render function, and especially how that's affected by suspense.

Throughout this, we'll learn that React can do unexpected things, like render your component many times without it ever committing. This behavior doesn't affect most components, but does add requirements for data fetching libraries, which should not leak memory or make unneeded network requests if React behaves in valid ways.

🔸Then, we'll talk about why, in light of what we've learned about React, fetching during render requires an external cache, and how it needs to behave.

🔸This has been implemented in the @isograph/react-disposable-state library. We'll look at some of the library's internals, then 🔸we'll end with a demo of a very simple custom data fetching library that is compatible with suspense.

�

5 of 28

Fetching in an effect

Doesn't integrate with suspense
Starts network requests last

All right, let's get started.

Okay, let's start off by looking at each time that we can start a network request. First,

🔸fetching in an effect.

Don't worry about reading this code, or really any code in this presentation, all that closely.

Here, we call useStartNetworkRequestDuringEffect, and receive an object that might be in a loading state.

Under the hood, React is waiting until this component is mounted, then firing effects. During those effects, we start the network request. You can think of it as starting the network request in a componentDidMount method.

We can identify this pattern because it 🔸doesn't integrate with suspense. It can't integrate with suspense, as suspense prevents effects from happening, and in this pattern, we wait until an effect occurs to start the network request!

It takes the longest to start network requests🔸 with this strategy for two reasons:

React runs effects after the render phase completes. So a network request that was started during or before the render phase necessarily starts sooner than one started during an effect.
But, it's worse than that. You risk introducing network waterfalls if you're mixing components that fetch in an effect and those that suspend. Effects don't run until after all components unsuspend, so a component that suspends pending the result of a network request can prevent MyComponent from starting its network request until that network request completes.
Many existing libraries only support this kind of fetching, as suspense for data fetching has been described as experimental until recently. But, they're adopting suspense for data fetching. So, you might encounter this issue when updating versions and migrating queries from being fetched during commit to being fetched during render.

6 of 28

Fetching during render

7 of 28

Fetching in advance

8 of 28

Fetch on click

Fetch on hover

During render

Let's say you have a multi-page form, and the user navigates from page 1 to 2. You want to fetch the data you need for this page.

🔸 Well, one thing you can do is to start that network request when React attempts to render page 2. Convenient! That's what we're showing now. The user clicks the button, the next page renders, we make a network request and, when that network request completes, we can fully render the content.

But we can do even better. 🔸How about loading the network request when the button to navigate to page 2 is clicked, and passing the request as a prop to the content component! As you can see, the network request started sooner, and it takes less time to show the user the full content.��Okay, okay, okay, it would be fair to point out that you're only saving a few milliseconds if you start a network request when a user clicks this button, vs. when it renders. In some cases, that might be true: a small improvement in performance. But it might be a bigger deal if something stops page 2 from rendering. For example, the app might throw up a blocking modal for some reason. Or, a component that surrounds page 2 suspends, preventing page 2 from rendering for some time. Now, we've lost quite a bit of time!��In any case, milliseconds can count at scale.

But we can do better: You can start that network request when the user conveys their intent to navigate to page 2. Say, if they 🔸hover over that button. And would you look at that, the network request has been started sooner and the user sees the content even faster. Or, we could even just load the data for page 2 as soon as the user navigates to page 1, under the optimistic assumption that they will continue the flow.

So, TLDR, preloading provides the best perf for users, and you should employ this strategy wherever possible.

��

9 of 28

	Fetching in�an effect	Fetching during render (lazy)	Fetching in advance
Perf	Worst	Medium	Best
Loading states	No suspense	Yes suspense	Yes suspense
DevEx for�app devs	Medium, you must handle loading states	Simple	Medium, requires passing props
Network waterfalls? 😡	Yes	Yes	No
Hook implementation complexity	Simple	Hard	Medium

Okay, so let's review the three different fetching strategies.

On the first row we compare perf, by which we mean "how soon does the network request start". Like we've said, fetching in advance is best, followed by fetching during render, followed by fetching in an effect.

Next, let's move down a row and talk about the user experience of loading states.

Loading in an effect is the worst, as with this strategy, you're unable to integrate with suspense, as we previously discussed.

Suspense has the advantage that it allows developers to show the right loading states for their app, rather than have those loading states be dictated by how we broke the UI into subcomponents

So, loading in an effect gets a red box here, while the other two strategies, which can integrate with suspense, get green boxes.

-----

But suspense also has advantages from a developer experience perspective, as it means your components can be written assuming that they're on the happy path.

So, on the next row, where we compare the developer experience of each strategy, we see that loading during an effect get a medium, because you have to handle loading states in each component.

Fetching in advance also gets a medium, as in a large, complicated app, it can sometimes be hard or impossible to figure out exactly what state change caused the component which needs data to render. For example, imagine an app backed by a Redux store in which whether a modal is displayed is a complicated function of Redux state. It might not always be easy to deduce which state change caused the modal to render, and so who should make the network request.��And in cases like that, the developer experience of fetching during render really shines. You can integrate with suspense and only deal with the happy path, and you don't need to figure out why a component renders, it can just fetch its own data.

---------

In the next row, we note that loading in an effect and loading lazily can lead to network waterfalls. Let's take a quick detour to see how.

10 of 28

Network waterfalls

Inner Network Request

Outer Network Request

In this example,🔸 this component is divided into an outer component, in blue, and an inner component, in green. Both fetch their own data when they are rendered.��So, to start, 🔸 this outer component renders and starts a network request, suspending until it completes.

Once that outer network request completes, 🔸, we can render the outer component without suspending. And React can render the child component, starting its network request.

🔸 Finally, once that network request completes, we can see all the content.

This is a bad user experience — the content loads later than it needs to, and the loading states we present to the user are ad hoc. And it'd be a lot worse if there were dozens of components loading data, creating dozens of network requests!��Apropos of completely nothing, this fortune 500 company's logged in dashboard page shows quite a few network waterfalls. This performance can be vastly improved.

11 of 28

	In effect	Render (lazy)	In advance (preload)
Perf	Worst	Medium	Best
Loading states	No suspense	Yes suspense	Yes suspense
DevEx for�app devs	Medium, you must handle loading states	Simple	Medium, requires passing props
Network waterfalls? 😡	Yes	Yes	No
Hook implementation complexity	Simple	Hard	Medium

So, we just established that fetching in an effect or fetching lazily can lead to network waterfalls. Loading in advance is not vulnerable to network waterfalls, as you have to know in advance all the network requests that need to be made in order to pass the correct props to the child components.

----

Okay, let's go onto the last row, hook implementation complexity. I don't want you to over-index on this. You implement this once, and then fetch many queries!

Loading in an effect is simple, and a solved problem. It's the only loading style that doesn't require a framework.

Loading in advance is fairly easy. Most of the time, it's equivalent to storing the network request in state. But you have to be careful — some state changes may never commit, and multiple state changes can be batched. So, if your network requests require cleanup, then there's some subtlety and this does require a specialized hook to ensure there are no data leaks.

But if they don't require cleanup, then you can get away with regular-ol useState!

Lastly, there's loading during render. There's a reason this whole presentation is devoted to just fetching during render, so let's give it the scary red box it deserves. 🔸

--------

Okay!

12 of 28

Why support fetch during render?

During render ⋙ during an effect
During render/effect is necessary if you don't know why a component is rendering
Necessary at the root of every page absent router integration

So, the point of that comparison is to help us understand: what are the options for fetching data, and why should a data fetching library even support fetching during render?
After all, it's the most complicated of the three. Existing libraries do just fine without it. Let's stop overcomplicated things for the sake of overcomplicating things!
🔸 Well, it should be clear that fetching during render is preferable in almost all cases to fetching during an effect. Importantly, it loads the data faster, and that's a pretty important aspect of user experience.
🔸 And secondly, sometimes fetching during render or an effect is necessary. Specifically, it can be hard to find the exact state change that caused a component to render, and start the network request at that time.
🔸 And finally... how can you start a network request in advance if it is read by a top-level component, say a Route component? Rendering the Route is literally the first thing that happens!
Well, not quite, there's the router. And if your router can understand prefetching and make the network request for you, it can pass it as a prop to the route. But if your router doesn't support prefetching data for your routes, the best you can do is to fetch during render or in an effect at the root of your page.

So that's it. That's why you should support fetching during render. It or fetching in an effect is sometimes unavoidable, and of the two, fetching during render is the clearly better option.

13 of 28

When does React render components?

Okay, so that's why we want to fetch during render. But before we can understand out how to implement that pattern, we need to discuss, in some details

🔸 When and under what conditions does React render components?

🔸 Well, consider this example component. It renders InnerComponent. Nothing too complicated.
At compile time, a babel transform will replace that JSX call with this 🔸 call to React.createElement.

Take a close look at that call to createElement on the right. The InnerComponent render function is passed in, but it is not actually called by the user. And, it turns out that React doesn't call the InnerComponent render function while OuterComponent is being rendered either!
In other words, it may look like OuterComponent calls InnerComponent, but that's not true. Instead, OuterComponent's render function will complete entirely before InnerComponent's render function is called.
This is a very important point.

This means that React renders each component individually, and React is in charge of when your component's render function is called.

14 of 28

Since React renders components for you

Hooks
State
Suspense

...for data fetching?
How many times?

So, since React renders components in isolation, and chooses when to render them, what are some of the consequences?

Well, for one, 🔸 hooks are possible! Have you ever wondered how they work? Why do multiple identical calls to useState return different values?
Well, that's because when that useState hook runs, it asks React — which component are you currently rendering? Give me that component's state.
React can only do this because React controls which component is rendering, and components don't subvert this by directly calling each other.

🔸And if some state changes, then React needs to know to just re-render the component that owns that state. If some parent component had directly called this child component, then React wouldn't even know about the existence of the child component, and thus wouldn't be able to re-render just the child.

🔸Next, this is crucial to how suspense works. So, let's consider this example.
A component suspends by throwing a promise, basically meaning that if data is unavailable, we can short circuit and stop a component's render function early. Later, React will re-render the component, and if that data is present, we don't need to suspend and can proceed. Thus, the component is written as if the data is always there.
Imagine if OuterComponent called Components 1 and 2 directly. Well, if Component1 suspended, that would short circuit execution and we would never call Component2's render function!
But, with Suspense, since React is rendering each component independently, it means that even though Component1 suspended, React is still free to attempt to render Component2, which it does.

🔸So, how does that affect suspense for data fetching?
Well, imagine if both Component1 and Component2 fetched data during render. If we short circuited before reaching Component2, that means that Component2's network request wouldn't start until Component1's network request ended. We would effectively be creating a network waterfall! Suspense lets us avoid that.

🔸 And how many times can React render a component? Well, consider Component1.
It will render once initially. During that render let's say some component suspends.
Then, when it unsuspends, React will re-render the whole tree, including Component1.
This second time, a component suspends, yet again! When that suspense is over, Component1 will be rendered again. This cycle can continue indefinitely.
So, as you can see, any component can be rendered by React an arbitrary number of times.

15 of 28

❗❗❗ Key points ❗❗❗

Any component can be rendered any number of times

16 of 28

Pre-commit behavior of hooks

17 of 28

No identity

Pre-commit, components have no sense of identity
If a component suspends before committing
Hooks re-instantiated (useState, useRef, useMemo, useCallback)

— useMemo documentation on react.dev

18 of 28

❗❗❗ Key points ❗❗❗

Pre-commit, you cannot rely on hooks to store information

Any component can be rendered any number of times

19 of 28

Use an external cache

Deduplicate identical requests
Ability to identify requests across renders
getOrCreate(requestId)

As far as I can tell, the only option is to 🔸use an external cache. It is traditionally passed through context, but a global one or one passed through props works just as well.

What should our cache do?

🔸 Deduplicate identical requests

In particular, if a component renders, makes a network request and suspends, then re-renders, we'd really like to re-use that previous network request.

And since we need to know which request to re-use, we need the

🔸 Ability to identify requests across renders. Basically, I just mean that every request needs to have a stable ID, say derived from the URL and parameters.

Basically, that sounds like we need a cache with a 🔸 getOrCreate method. Every time we would otherwise make a request, we first check if its in the cache. If it's there, return it, if not, fill it with a new cache item and return a reference to that.��

20 of 28

Clean up our network requests

Garbage collection
Close web sockets
Effects?

This is great. An external cache with a getOrCreate method is suspense compatible and sufficient for a good chunk of websites. Not bad!

But what if we wanted 🔸 to clean up our network requests when we're done using them, for example to 🔸garbage collect the network data and reclaim memory?

Or, what if want to also 🔸 open websockets to other data sources, and would like to close them when they are no longer in use, to avoid doing unneeded work?

There's nothing in this presentation that is specific to fetching data. We're just loading resources, and making a network request for data is just the most obvious example of that. But we could be opening web sockets.

Well, continuing with our theme of not overcomplicating things, the usual way a component performs cleanup is via 🔸 useEffect. This hook allows you to schedule a cleanup function. Okay, so let's learn more about the effects phase to see if that makes sense here.

21 of 28

Effects phase

22 of 28

❗❗❗ Key points ❗❗❗

Any component can be rendered any number of times
Pre-commit, you cannot rely on hooks to store information.

A successful render will not always be followed by a commit.
You can't rely on an effect's cleanup function to clean up side effects made during the render phase.

23 of 28

What to do?

Commit => clear the temporary retain and transfer ownership

Component renders...
Set a timeout: create first temporary retain

RᴇꞯᴜᴇꜱᴛCᴀᴄʜᴇ(ɪᴅ)

Empty

CᴀᴄʜᴇIᴛᴇᴍ

◇ Temporary retains: 0

◇ Permanent retains: 1

Render 1

RᴇꞯᴜᴇꜱᴛCᴀᴄʜᴇ(ɪᴅ)

CᴀᴄʜᴇIᴛᴇᴍ

◇ Temporary retains: 1

◇ Permanent retains: 0

Render 1

Okay, so we've established that we need an external cache with a getOrCreate method, and when we want to make a network request, we first check the cache and reuse that network request, if it's there, and otherwise add one to the cache and use that one. And now, we've decided to add garbage collection to this cache, and we've determined we can't use effects for this.

So let's consider what we'd want to happen if

🔸 React renders a component, which starts a network request and populates the request cache. We don't read the network request in that component, so its render function completes successfully. Then... nothing. Maybe the parent unmounted, or another component errored. This component will never commit. No code related to this component will ever be called again.

Remember, one of our key points was that a successful render will never know whether it will eventually commit.

In this situation, the best we can do, when we populate the request cache, is to also schedule a 🔸 timeout to potentially clean up the cache item. We call this a temporary retain.

🔸 So, after one render, our request cache contains a cache item with one temporary retain.

🔸 If the component next commits, we can clear the temporary retain that we created during the render. Which is to say, clear the timeout. We replace it with a permanent retain.

🔸 Now, since there are no more active temporary retains, we move the cache item out of the cache.

The component now references the cache item directly, and the request cache would appear empty if another component tried to make this same API call

24 of 28

What to do?

Renders again

Component commits
Clear other temporary retain, and transfer ownership
Keep other temporary retain

Post 1

(LOADING AUTHOR PHOTO)

Post 2

(LOADING AUTHOR PHOTO)

🎉

RᴇꞯᴜᴇꜱᴛCᴀᴄʜᴇ(ɪᴅ)

CᴀᴄʜᴇIᴛᴇᴍ

◇ Temporary retains: 2

◇ Permanent retains: 0

Render 1

Render 2

RᴇꞯᴜᴇꜱᴛCᴀᴄʜᴇ(ɪᴅ)

CᴀᴄʜᴇIᴛᴇᴍ

◇ Temporary retains: 1

◇ Permanent retains: 1

Render 1

Render 2

Now, what if, instead, that first render doesn't commit, and the 🔸 component renders again?

Concretely, we might see two renders if the component made the network request and immediately tried to read it, suspending. When the network request completes, it unsuspends and the component is rendered a second time.

But remember that one of our key points was that, pre-commit, components have no sense of identity, so we don't know whether those two renders come from a single component or from two components.

At this point in time, the request cache contains a cache item with two temporary retains.

🔸 Okay, so when one of those renders, say render 2, commits, what can we do? Well, we can replace one temporary retain with a permanent retain, but there is still that other pesky temporary retain.

With the other temporary retain, we can:

🔸 Assume that both temporary retains came from a single component, and clear it, transferring ownership to the component, like we did on the previous slide. The cache will be empty, and the component will directly reference the cache item.

🔸 Or, not make this assumption, and keep the other temporary retain

It's not obvious what to do here. Some queries, like the root query for a given page, will likely not be rendered by two distinct components at once! It might happen if you navigate very quickly between a few pages in concurrent mode, but in general it probably won't happen.

But imagine a 🔸list of posts, each of which lazily loads the profile picture of the author. Two of the posts have the same creator.

Let's see what happens. Both posts render. The first author component renders, and starts a network request for the picture. The second one starts rendering, reusing that same picture request and fetching some unrelated data. The picture request completes, and the first post unsuspends and then commits.

We change one temporary retain into a permanent retain, and clear the other temporary retain. Now, since the cache item has zero outstanding temporary retains, we remove it from the cache.

The second post was busy fetching some other data, so it took a bit longer to unsuspend, but it eventually unsuspends. When it re-renders, it finds that the cache is empty and, guess what — that means it needs to only then start its request for the author's profile photo.

Whoops! By disposing of that second retain, we've introduced a network waterfall. That's really not good.

This isn't even a farfetched example.

🔸So, let's only convert one temporary retain to a permanent retain, and keep the previous outstanding temporary retain.

🔸 So jumping back to the original example, in which a component rendered twice and committed once, we see that our request cache is populated with an item with one temporary retain, and one permanent retain. That permanent retain is cleared when the component unmounts. The cache item will only dispose of the underlying network request when all temporary and permanent retains have been cleared, meaning that the component that has mounted can be sure that the network request will not be disposed before that component unmounts. That's great!

The disadvantage here is that if the component unmounts before the temporary retain times out, the network request won't be cleaned up until after a delay.

25 of 28

What to do?

Refetch when a new component renders

RᴇꞯᴜᴇꜱᴛCᴀᴄʜᴇ(ɪᴅ)

CᴀᴄʜᴇIᴛᴇᴍ

◇ Temporary retains: 0

◇ Permanent retains: 1

Component

RᴇꞯᴜᴇꜱᴛCᴀᴄʜᴇ(ɪᴅ)

Empty

CᴀᴄʜᴇIᴛᴇᴍ

◇ Temporary retains: 0

◇ Permanent retains: 1

Component

Okay, so final thought experiment.

�What if both a component renders, suspends and commits, but then the first render's temporary retain expired? Meaning that there is now one permanent retain?

�Now, after this component mounts, what happens if a new component renders and wants to make the same network request? Should we re-use this network request?�

🔸 In my opinion, the best behavior here is to refetch. Nobody wants to see stale data forever. And besides, you can always add a layer on top of the simple network request cache that prevents duplicate requests in some cases.��And, remember, we said we would do only the caching that suspense required. Well, let's put that in practice and have new components rendering refetch. So, what should the cache look like?

🔸 It might be non-empty, containing a cache item with one permanent retain. The committed component directly references the cache item. But... then when another component renders, the logical cache behavior would to add a temporary retain and reuse the network request, and not to re-create the network request. This is the opposite of what we want.

🔸 So, instead, what we should do is empty the cache! Subsequent pre-commit renders will see an empty cache, causing new network requests to be made.

26 of 28

❗❗❗ Cache/Cache Item Behaviors❗❗❗

When making a network request, call getOrCreate
A pre-commit render results in a temporary retain
A render committing for the first time clears one temporary retain and creates a permanent retain
If there are no more temporary retains, the cache item is removed from the cache and used by existing components
If there are no more temporary or permanent retains, the underlying network request can be disposed

Okay, so the hard part is over, just one last slide. Let's summarize the behaviors we want our cache to have.

🔸 We have an external cache with a getOrCreate method, which we call whenever we might otherwise make a network request. It follows the following rules:

🔸 In a pre-commit render, we add a temporary retain.

🔸 If that render commits, convert one temporary retain to a permanent retain

🔸 Any cache item with no more temporary retains is removed from the cache, but can continue to be accessed by previous pre-commit renders and

🔸 If there are no more temporary or permanent retains, the underlying network request can be disposed

Okay! So that's the gist of how the cache behaves. Sure, there are lots of improvements we could do, but that's enough to get the job done!

Let's dive into some code. We'll start by taking a look at useCachedPrecommitValue, which is the hook that actually lazily loads a generic disposable item. From there, we'll look at how the cache works, and then look at the demo. Okay, let's go!

27 of 28

Code spelunking time

28 of 28

Suspense for data fetching:

How to fetch

during render

Robert Balicki ◆ ex-Relay team @ Meta

@StatisticsFTW ◆ robert.balicki@gmail.com

Hi folks, my name is Robert Balicki. Until recently, I worked on Relay, the framework for building React apps that consume GraphQL data, at Meta. You can follow me on Twitter at @statisticsftw.

Today, I'll be talking about suspense for data fetching in React apps. That's a big and scary subject 🔸, so we'll focus on one specific aspect of it: 🔸 how to start network requests when a component first renders.

�Sounds easy, right? Just make the darn API call! What could go wrong? A lot, actually. This is one of the toughest things for a data fetching library to get right.��So, in order to understand how a data fetching library can enable this kind of fetching, we'll need to learn about when and under what conditions React will render your components, and especially how Suspense affects that. After all that, it'll still be complicated, but I hope it makes conceptual sense.

And we'll finish this up with a demo of a very simple custom data fetching library that is compatible with suspense.�

This demo will make heavy use of a library of hooks that I wrote — the name of this library is @boulton/react-disposable-state