5 Ways To SSR/RSC on TanStack Start

Now that we have React Server Components and TanStack Start, let's talk about the five different ways to get data onto your page including SSR, non-SSR, RSC, all of the different variations. Let's get right into it.

Now before we get into it, I'm going to take a quick digression and just answer something has been coming up a lot recently. I'm not sure who needs to hear this, but React Server Components were not the first time that React did server-side rendering. Not by a long shot. React has always had server-side rendering even before Next. js. In fact, it's a pillar of the React architecture that it is isomorphic, meaning that React can render in both the server context and in the client context, and that has been since day one. Next came around because before Next, everyone was using their own DIY bespoke versions of SSR. Next just standardized those with what they're now calling the Pages Router and then added RSC support with what they're now calling the App Router. But at every point along that line, React has always been capable of being server-side rendered. It was just a question of how you want to do that server-side rendering. So let's talk about the five different ways that you can do them with TanStack Start. Starting off with not at all, the

client-side rendering version. So here is our example. It's five different ways to go and get the Pokémon list from the Pokémon API. You're not going to see any difference in terms of the UI really other than just explanations of what's going on. So what's interesting with the client-side rendering version is that the request to the Pokémon API is made off of the client in a classic single-page application or SPA way. But it's incredibly clean in TanStack Start, as you'll see. Here is the SSR variants project code. All of this is available to you for free in GitHub in the link in the description right down below. Of course, the index page simply has links to all of the variants. The one that we're looking at right now is the CSR page, and the critical component here is we've set SSR to false. That means that TanStack Start is not going to server-side render this page. It's only going to send the code for the page out to the client, and the client is going to do all the work. Now what happens here is that the TanStack Router then kicks in and the loader is fired when the page first starts up. That loader goes and makes the fetch top Pokémon from the API, and then the page component, in this case CSR page, uses route. useLoaderData to just go and get that Pokémon data that the router has choreographed in terms of loading this route. So it doesn't really matter if this is a hard nav or a soft nav to this page, the effect is always going to be the same. The router is going to manage getting the data from the loader before it actually renders the page. All right, now let's talk

about the server-side rendered version of this. So if I go over to server-side rendering here, we're not actually going to server-side render. That's actually a SPA nav between those two things, and in that case TanStack Start is going to do exactly what we did with CSR but just call it SSR. That's a feature, that's not a bug. If you do a hard nav like what I'm going to do now by refreshing the page, you can see over here, if we look at the page source, we can do a find Bulbasaur and it appears in the HTML. So it is rendering on the server and then passing it off to the client, and the client is actually going to do another re-render on the page. That's really important to know. That is the standard React hydration cycle, and it happens when you're not using RSCs. So when you look at the RSC variants coming up, those are only ever going to render on the server and then get sent down to the client. All right, now let's go take a look over at the code. In this case, I'm going to take a look at SSR. tsx, and in this case SSR is true, which is also the default, so you don't need to necessarily put that on there. But check out how we're doing the loader and the getting of the Pokémon. It's exactly the same between those two. How cool is that? Now there's

another SSR variant called data only, and we actually had this before we had RSC. This is really cool, especially if you're doing something like a dashboard. Let me show you. So if we go back here to the home page and I go to data only SSR, and again I do a hard refresh, you can see that there's a slight flash here as it brings in the data. So what's actually happening? Well again, if we look at the page source, we can see that we have no HTML for Bulbasaur, but we do have data for Bulbasaur. So the data is being fetched on the server, then being sent down to the client for rendering, and that's why you see that little flicker there. Is that the server is getting the data, it's sending it down to the client, and then the client is the only place that's actually doing the rendering. Again, super handy for something like a dashboard where you don't want to go and CDN cache the contents of the page, but you do want to get data off the server, probably more securely than off the client, and then pass it down to the client for render. So let's take a look at the code for this. Again, exactly as we had before, but in this case we're just saying SSR data only, but it's exactly the same code otherwise. All right, now let's talk

about React Server Components or RSC support in TanStack Start. So the first thing you need to know is that I've enabled RSC support by bringing in the VJS plugin for RSC and then simply enabling RSC on the TanStack Start V plugin. Super easy. Let's go take a look at the page and we'll try out render server component. So this is using the RSC low-level API. TanStack Start actually has two ways of doing RSCs. You can do them in combination, you can do one or the other, or you can not use any RSCs at all. Totally up to you. All the options are open. Let's go take a look at how this is done. So we'll go over here to RSC renderable, and we can see that we have a new component at the top of the page, Pokémon server list. And importantly, it's an async component just like you'd have in the Next. js App Router. We're going to go and await fetch top Pokémon. Super easy way to go and get your data in here. Then we render those top Pokémon, and that server function uses render server component with that component, just JSX like you'd expect, and that gets back a renderable. We're going to return that as Pokémon list, and then you can start to see where this intersects with the architecture that we had before. We're using the same loader like we had before. SSR is true, and we are getting that Pokémon renderable, returning that as loader data, and then we break that out in our page. We get Pokémon list back, and then we just simply drop that into our JSX wherever we want it. It's just a remarkably clean and simple architecture. Now if we go back to the route definition again, think about what the loader is doing here. It's just getting Pokémon renderable. It could actually go and get other data. It could render other RSCs. Whatever you want. You can go and just have as much of a combination of architectures as you want in that loader, and TanStack Start is going to do all of the work of coordinating all that. Now let's take a look at our final

fifth version of this, and that is the composite component version. So I'll go over here to RSC create composite component. And as you can see, exactly the same output as that we had before, but what in this case we're doing is we're returning a shell of a component to the page, and then the page can go and actually slot in dynamic components. In this case, we've created a client [snorts] slot where that composite component can go and take interactive components. So when you think about how you might want to architecture like a page shell, that's where you want to think about this RSC composite API that is unique and specific to TanStack. Let's take a look at the code. So over in RSC composite, we can see again the Pokémon server rows just like we had before, an async function. Now in this get Pokémon composite server function, we call that create composite component and give it a component. This component is actually defined right here. It defines the shell of the layout and then takes any children and pops them in there wherever you want. You can also have as many slots as you want defined on these composite components. So you can have like a call to action section or an ad section or however you want to layout your shell. Then down in the create file route, again we're calling that loader. If you haven't noticed, loaders are really important here. We grab in this case the source for the composite component, and then we pass that to the composite component as source, and then we give it any kind of slots we have. In this case, we have the children slot, so we just drop in a paragraph tag and that's what will go in there. If you have interactive components, those can go in there, and you don't need to use client. But I'll get into more of that in another video where we really drill down into the differences between the low-level API and the composite component API and how and when we want to use those two. In the meantime, I

hope this has given you a nice overview of how TanStack Start manages server-side rendering and RSCs and five different combinations of the above. If you have any questions or comments, be sure to put that in the comment section right down below. In the meantime, if you this video, hit that like button. If you really like the video. Hit the subscribe button and click on that bell and you'll be notified the next time a new Blue Collar Coder comes out.