Hi, my name is Julian, and I'm extremely excited to talk about suspense. Suspense allows you to render fallback UI while waiting for asynchronous tasks to resolve, making it the unsung hero of React components. In today's talk, I will explain why suspense is crucial for React server components. Before diving into server components, let's understand the history of web rendering and the problems it posed. We then introduced server-side rendering (SSR) and static-side generation (SSG) to address these issues. However, SSR had problems like large bundle sizes, slow hydration, and sluggish initial server response time. React server components solve these problems by allowing us to differentiate between static and dynamic components. But to address the third problem, we need suspense. Today, we'll build a simplified version of suspense on the server to demonstrate its conceptual working and how it improves the rendering process from classical SSR to streaming and out-of-order streaming. Let's dive into the code by building a movie app called Notflix. We have different sections like the title, cast members, and similar movies. The components fetch their own data asynchronously, making them server components. In the classical way of server-side rendering, we loop through the children, execute them as server components, and render the HTML response. To improve the user experience, we introduce streaming, which allows us to start the response on the server, keep the connection open, and add to the response document as data becomes available. By using the write method provided by Express, we can write to the response stream instead of collecting all the HTML. Dealing with promises in sequence ensures that components are rendered in the correct order. Although the server-side rendering has improved, there is still no loading state or proper handling of suspended children. To address this, we introduce suspense on the server and build a suspense component with a fallback UI and children. We keep track of suspended children using a simple object with unique identifiers. In the renderer, we check the suspended object and loop through the entries to handle each suspended child. To replace the loading state with the content once it's available, we need to execute asynchronous functions to collect and concatenate the content, delete the entry from the suspended object, and use JavaScript to handle the swapping of elements in the browser. To replace the fallback renderer with the content, we need to wrap the fallback in a diff and add an identifier using a data attribute. We can use the CSS trick of 'display: contents' to prevent the diff from affecting the layout. Next, we wrap the available content in a template tag to add it to the document without rendering. Finally, we use custom elements and a connected callback to swap the loading boundary with the content based on the identifier. This allows us to replace multiple fallback renderers. By wrapping each section in its own boundary, the user experience is significantly improved as each section can load independently. This approach also emphasizes the importance of using the platform's existing features and functionality, such as browser caching, to enhance performance. Thank you for watching and enjoy the rest of the conference!
