When it comes to testing library code, the (usually amazing!) “Testing Library” approach quickly hits its limitations: We often need to test hot code paths to ensure additional guarantees, such as a specific order of DOM changes or a particular number of renders.

As soon as we start adding Suspense to the picture, it even gets almost philosophical:

• How do we count a render that immediately suspended, and how do we distinguish it from a “committed” render?

• How do we know which parts of the Component tree rerendered?

In the Apollo Client code base, we’re using the React Profiler to create a stream of render events, enabling us to switch to a new stream-based testing method.

After testing this approach internally for a year, we have released it in a library that we want to present to the world.

Nehmen wir an, wir haben eine App mit ein paar Serverkomponenten und ein paar Clientkomponenten. Was passiert da eigentlich auf dem Weg vom Server zum Server (ja, richtig!) zum Browser?

Ein paar kleine Spoiler: Es gibt mindestens einen Stream im Stream. Manchmal transportiert der Stream im Stream sogar noch weitere Streams. Darüber hinaus spielen noch eine Handvoll neuer Pakete (manchmal auch dasselbe Paket in unterschiedlichen Ausführungen) und Bundler-Plug-ins eine Rolle.

Wir schauen uns das an, und wenn die Zeit reicht werfen wir sogar einen Blick in den React SourceCode.

If you use the Next.js app directory, you might not even have noticed it, but you are not only using React Server Components, but you are also using the new streaming SSR feature of React.

That means that on first page load, your Client Components will now be server-side rendered, suspense boundary by suspense boundary, and constantly streamed to the client, where they are rehydrated piece-by-piece.

If you combine that with suspense for data fetching in your client components, you will suddenly be facing hydration mismatches - as your client components will start fetching data on the server, but the data will not be transported to the client.

In this talk, I will go over the rocky journey that we had to go through to support suspense for data fetching in Streaming SSR with Apollo Client, looking at all the curious timing problems that come up with these technologies, and how we try to solve them as best as we can - always with the best possible user and developer experience in mind.