Race Conditions

[00:00] Let's go into our UI index right here. And what we're going to do is keep track of the latest request that's going out and only process the request when we are the latest. To keep track of that, we're going to make a latest nav, ref, nave, use ref.

[00:17] I make that mistake all the time and it makes me chuckle. Latest nave. All right, so then we have our latest nav.current. We'll assign this to a new symbol. Using a symbol is not totally necessary, but it comes with the benefit of being 100% unique and we can also give it a label.

[00:36] So we'll say symbol, and this is going to be our nav for the next location. And so if we were to console log this, we would see, oh, which navigation was this for? And so then right here, all we need to do is say if the latest nav,

[00:54] oh, actually here, we need to give this a variable name, so let's say this nav is equal to that and then we assign this to this nav. There we go. So then I say if the latest nav.current is no longer this nav, so we've navigated again since this request was made,

[01:13] then we can just exit early. And then otherwise we'll continue to do the regular stuff we were doing. So if I come back here and I say star, then you'll notice we do not process the response that comes back. You can also take a look at the network and just make sure that things are happening the way that you would expect them to.

[01:33] So very importantly to check out the waterfall here. So I say star. Each one of these is going to be coming in a different order. They are streamed and so the waterfall looks like that's not quite showing here. Let's try that once more. Why is the waterfall not showing? What the heck?

[01:53] There we go. If you have this problem, there you go. I just taught you how to show the waterfall again. Okay, so let's try this once more. Clear all this out. And I type star. And you'll notice that one showed up way later. This totally happens in production. Almost never happens during development because you're running with the server

[02:13] running on your machine. And so it's just not something that people think about a whole lot, but it absolutely happens in production. You want to think about this when you're building your apps. And this is the sort of thing that a framework should handle for you. But since we're building framework, I wanted to make sure we handled it. So there you go.

[02:30] That is handling race conditions by simply creating a ref that will keep track of the latest navigation. And after the asynchronous stuff is done, if that isn't the latest navigation anymore, then just don't do anything about it.

[00:00] What we're going to talk about here is a bit of a optimization that typically your framework is going to manage for you, and so we don't normally need to go too deep on these types of optimizations for your understanding of React server components.

[00:14] But I just couldn't let myself let you make this mistake or forget about thinking about race conditions. And so we're going to think about race conditions. If we open up our app.js file in the server, we're going to find that our friend Kelly,

[00:31] the coworker, has added this little bit of code to help us simulate a race condition. So if your search query starts with ST or is ST, then this particular event or request

[00:47] is going to take a little bit longer than the other requests. And so the benefit of this being we can just test out this race condition by typing star into the filter, and you'll see that the response comes back wrong. And so like this is kind of simulating how sometimes a network request can come into

[01:05] your server, and maybe it's really busy with something, and so that ties things up. And then another request comes in, and maybe it goes to a different server, your horizontally scaling or just the powers that be with computers, that request comes back first. So that describes basically a race condition. So we're simulating that right here.

[01:25] And if I type in star, you'll notice my search gets updated to ST. So once this response comes back, then our promise chain continues and we end up updating the URL. So we don't want to do that. So your job is to handle the race condition properly so that we don't have this problem

[01:45] with the URL. It's actually just a couple lines of code changed in our UI index. So let's get into it.

React server components (RSCs) are experimental and only used by a few frameworks...

Until this workshop! 

We'll be building this framework without any build tools. This means no TypeScript, no JSX, no Vite, nothing. We're going to be writing plain JavaScript and using Node.js\/browser native APIs to build our framework.

**That's right, you'll be building your own framwork that supports RSCs.**

You'll get into the nitty-gritty detail by: 

- Serializing and streaming your UI on the server to the client yourself with `renderToPipeableStream`
-  Granularly streaming in your server components with Suspense
-  Using Node's `AsyncLocalStorage` to **get context on the server.**
-  Registering and using a Node loader to implement your own "use client" directive
-  Building a full client router with history and cache
-  Implementing server actions

**This workshop follows the pattern of React Fundamentals but it's taken up 10 notches.**

After working through this you'll truly understand React Server Components from the ground up.

## Warm Up

In this section you will warm up by wiring together a hono.js app so that it serves static assets and data from an API endpoint. 

Whatever your server-side architecture, every web application will have these bits!

## Server Components

The idea behind RSCs is conceptually simple. Instead of requesting JSON data and handing that off to our components to generate the UI, we request the UI itself.

You'll learn how to serialize the UI on the server, stream it to the client, and then convert it to React elements that can be rendered in the browser.


## Client Components

To provide a great user experience, we still want to have some client-side interactivity. 

Server and client components can be intermixed but there are nuances to how this is accomplished. Once you complete this section you'll understand why server components can render client components but not vice versa.

You'll also see why the `"use client"` directive is used, and implement the handling of those modules yourself.

## Client Router

Learn to build a client-side router that integrates with your React server components. 

You'll manage navigation without full page reloads, fetch and display updated UI content from the server, and create smooth transitions with pending UI states. You'll also handle browser history for back/forward button support and implement caching.


## Server Actions

This section starts off with implementing the `use server` directive to designate server action functions and manage their serialization process, which, unlike client components, doesn't require full module serialization.  

You'll then build the server-side request handling: extracting action identifiers from RSC headers, utilizing dynamic imports to load the corresponding server-side function, and finally, executing the action and returning the result to the client. 

Finally, you'll explore a couple strategies for revalidating your UI after a server action is executed.


Understand React Server Components and Server Actions by building a framework with them using just the Browser, Node.js, and React.

React Server Components

React Server Components

Transcript

Race Conditions

Transcript