Partial Page Caching Using React Server Components

Ever since TanStack Start got React Server Component or RSC support folks have been asking me for use cases that justify RSCs. Okay. I'll give you one right now. But before we get into it, let me just set it up by saying that you're not gonna see a one size fits all demonstration of React Server Components as a value add for every type of site out there, because I just don't think that exists. The way that TanStack Start views RSCs is as a very specific tool for very specific sites that might need it. It doesn't look at it as something that every single site needs. Think of it like this, for example. This is a general purpose tool. It's a cordless drill. If you don't have one, you probably should. It's great for doing all kinds of things. You can drill stuff, you can screw in screws, you can do all kinds of stuff with it. But sometimes. It's way too big to get into where you want to go with it. So you bring in a specialized tool like this right angle adapter here that allows this big tool to get into tiny little spaces where you need it. Very specialized tool, very general purpose tool, and that's really the way that you need to think about RSCs. Very, a very. Specific tool that you only need at very specific times, but when you need it, you really need it. And that's where RSCs come in handy. So the use case I'm gonna show is around a content site. Now, on the left hand side here, we have the running TanStack Start application, and on the right hand side we have the exact same application, but it goes through a CDN proxy that I've set up. Now for content sites like this news site here, you do want to go through a CDN or Content Distribution Network for performance reasons. But the problem is that CDNs only cache at the level of a route. But what happens when, say you want to go and cache bust different parts of the page at different speeds. For example, the stuff in blue on the page route, we're only gonna cycle every so often, but the stuff in the trending box in yellow is something that we're gonna want to go and cache bust really often because there's new trending topics and all that. So how can we fix that with RSCs? Well, the first thing I'm gonna do is only talk about the CDN version 'cause that's the only thing that really matters here. And now let me start off by just showing you how this application is run. So I go back over here to my Cursor and then we can see that I've got two side by side terminals. I'm gonna use this terminal to go and add stories interactively, and I'm gonna use this terminal over here to run the CDN, which is then going to proxy port 3000. And I've got that just runs both of them simultaneously. So I'm gonna do that. And I'm gonna clear this terminal. I'm gonna go over to my CDN site and hit refresh. And you can see that there's a bit of a delay there. As all of the assets are cache misses . We're missing the page, we're missing the RSC content. All of that has to be cached. And then on the next request, so refresh again, we can see that there's a cache hit across all those, and the page is much, much, much, much, much, much faster. Now with that in mind, let's talk about how that trending column is done, because this is where RSCs come into play. Here's our index route, We have our left hand content with all of our articles. Then we've got our TrendingClient, which is wrapped in a PPCFragmentRegion. That's just really giving that, that display of the bordered region around it. There's nothing special there. TrendingClient, is what actually requests an RSC from the server. So you can see over here we use a use effect and we call getTrending. And then once we get that back, we have our RSC, that's a ReactNode. Once we have it, we just simply render it into a fragment. What does getTrending look like? Well, if we go over here to trending, we can see getTrending. Now of course, all this codes available to you for free in in the link in the description right down below, so you can go and test this out for yourself. Now getTrending. We use a server function. It's a GET request server function. That's really important in this case because CDNs can really easily cache GET requests they can't so easily cache POST requests. And then we're gonna use the renderServerComponent function. That is a unique feature of TanStack Start and it's RSC support and in particular the Low Level API. So we are just getting back the flight data of Trending and we're sending that back to the client. In fact, I can show you that right now. So if I go back into my browser, I go to the inspector, I go to network, I hit refresh. We can see right down here this request to a server function with this gui. And the response is essentially binary flight data packed into Seroval. I think. It doesn't really matter for this because the CDN likes caching, whatever it is that you have, and what's really important is that the client can then take that flight data and then just render it into the VDOM really quickly. So now let's see this in action. Let's add a story to this. Go back over to my terminal. I'll add a basic story. Call it "Basic Story Test 1". What that has done is fire a request over to our port 3000 server to go and add that story and then we made another request to invalidate the tag for the trending component. Now that tag and validation system isn't part of TanStack Start. It's not built in. It's just a feature of this particular example. So we can see down here, we missed on that server function, which means that the cache is invalid, which means that we went back to origin and got new content for that RSC. And we can see the "Basic Story Test 1" show up here. Great. And if we hit it again, we're back into the world of being cached again. Now you might be saying, okay, cool, Jack, that's fine, but I could do this with a JSON payload, which. Touche. That's true. You could have that server endpoint return, JSON, which is then rendered on the client. But here's the problem. All the code for rendering all of those articles needs to be on the client and it has to run on the client in response to that JSON payload coming back, which is slower than what you're gonna get from RSCs. 'cause the RSC flight payload has all of the VDOM already rendered, and all it's gotta do is just jam it into the existing VDOM and render it. There you go. So counterpoint, it is faster to use RSCs, but here's where it really gets interesting. So you notice that I added a basic story. Well, there's a different type of story. Each story can be either basic or interactive. So I'm gonna add an interactive story. Now again, we go and we see, oh, there we go. The interactive story is there. And the interactive story is well interactive, so I can click on More Info here and we get an alert, which means that it is a client component. So we go back over into our code. We can see that an interactive story has "use client" at the top. When you're using the Low Level API, you need to use "use client" to tell the bundler that this is going to be an interactive component. Here's where it really gets. Cool. So let's take a look at the inspector and the network tab. Now if I do refresh, you can see that. Now, in addition to getting the RSC payload, we also got the JS code to run that interactive story. It wasn't in the initial bundle, and that's really, really important. So that's the real key differentiator here. We can have all kinds of different interactive components, but we don't have to send those all down in one mega bundle to the client. We can just go and send down RSCs and when those RSCs invoke those particular components, then we will load the code for those components if they're dynamic. It is really cool. Now I get that this video is really in the weeds. This is old school, blue collar coder type stuff. But. I gotta say, if you run a content site, this is going to be really interesting to you. And if you run other types of sites, like dashboard sites, we have all kinds of different widgets and you, the customer is only gonna use one or two of those widgets, but you've got a bank of them. This is the kind of stuff where RSCs really help. So if you're the person that's been hounding me to get, what's the real use case for RSCs? Think about things like this in your context. Maybe RSCs are a tool for you that helps you solve those kinds of problems. You shouldn't be architecting a full framework around RSCs. They're a special purpose tool for very special purpose circumstances. That was just one idea that I had for using RSCs in a very specific way. If you have more ideas, be sure to put those in the comments and maybe we can make a video around your use case. In the meantime, if you like the video, hit the like button. If you really like the video, hit the subscribe button and click on that bell, and if you notified the next time new Blue Collar Coder out.