Tanstack Start and How It Supports React Server Components

Who has heard of 10-Stack Dart before today? Great! And who has built an application using 10-Stack Dart before today? Right. So for the two or three of you who didn't raise their hand, I will give a quick introduction.

10-Stack Dart is our full-stack framework for client-first applications. It's built on top of 10-Stack router, so it has type routes, search state, type loaders, everything is typed, we have a router cache, and many more features. On top of that, we layer server features when you need them, so, for example, streaming SSR, server functions, middleware, and end-to-end type safety. Start is supported by Weed and RSBuild, and we have adapters for React and Solid.

Today, I'm going to be talking about React server components, and they only apply to the React version of Start, but we generally have one design theme which is we build primitives that compose and you will see that our RSC design also follows the same idea. Before we talk about how 10-Stack Dart handles React components, I want to pull back the curtain a bit on what RSC actually is. In many frameworks, the RSC pipeline is hidden. You write files, you add directives, and the framework decides how server components are rendered, how the result is decoded, and eventually how HTML comes out of that.

Let's separate the React mechanism from any framework architecture. At the React level, there are two co-operations necessary for RSC. First, rendered to readable stream runs in the RSC render environment. Server components execute there, and client components become references. The result is a data stream for React, and that is not HTML. That proprietary protocol is called flight internally by React. The second step is a function called create from readable stream, and that runs on the consumer of that stream, so it decodes the stream into a renderable React value. Two common consumers of that stream are the browser and the SSR environment.

In the browser, React decodes the RSC stream and reconciles the result into the existing DOM during client-side navigation, and that doesn't involve SSR at all. During SSR, the React decodes the stream again, passes the result into React DOM server and produces HTML for the initial document response. Just to clarify, RSC is not SSR, and RSC just produces data for React, and SSR is just one possible consumer. Once we see RSC as just a payload, the rest of what follows now will follow naturally. You can fetch it, cache it, invalidate it, persist it, and compose it.

Before we go deeper now, I want to make one thing explicit. You might not need React server components. A lot of people associate a lot with RSC, but they don't actually need them. You do not need RSC to stream HTML. Plain React SSR with suspense already does just that. You don't need RSC to do data-loading on the server, and in 10 sec, start and load us. We do not need RSC to call the server or run mutations on the server. In 10 sec, start, we have server functions for that. So, we already have quite good primitives for those concerns, but there are cases where RSC is a really good primitive, and that primitive is server-rendered UI, and it really shines when UI rendering code is the expensive part, both in bundle size and in computing power.

Common use cases are markdown rendering, syntax highlighting, and overall just content-heavy static UI where the browser doesn't need the renderer but you want to ship the rendered result.

With that out of the way, let's look at how we treat React server components in 10 sec start. Remember the diagram on the first slide? RSC has two co-operations. First, the server renders RSC into a data stream, and then the consumer decodes it. So usually, those two core React functions are hidden implementational details, but in 10 sec start, we expose them in our low-level API.

So, the server function just calls render to readable stream, and this returns a stream of data. The React elements go in, and the flight stream comes out. Then here, a query function calls this create from readable stream to decode the flight stream back into a renderable React value, and, after that, you can just use this and render inside of your component next to anything else. But we're not just exposing these low-level APIs, we also have build abstractions on top of it. That means not every app has to pass around streams and needs to decode anything, so you can use the upper-layer APIs if you want to.

In that case, one of those calls render server component, which again is called here from the server function, it returns the stream but you don't know it's a stream, it's handled for you. Now, you can just call the server function, you don't need to decode it, and same as before, you can just render the result, it's a renderable React value. So, in 10 sec start, as we have already seen, the server functions are the boundary for requests and response of server-rendered UI. The client sends the input shape the render needs. In that example, that's just a slug, but it can be anything, so you're not sending the whole world to the server, you specify what you need.

On the server, you have a validator that validates that the data you're passing in is actually the thing you expect, if not, error is raised and you're not continuing, otherwise, the handler is called, and it will use the validated input data, in that case, it's just a slug, and it will call render server components to pass in the JSX you want to actually render. Now, as I said before, we have primitives that compose, so, in that case, since this is a server function, you can just use a middleware and apply that and move out common stuff that you typically have around a HTTP call. In that case, since this is just HTTP, really, you can set response headers, in that case, we set cache control and CDN cache control, and that means that server rendered UI will be cached by both the browser and, even more importantly, on the CDN level, which is nice for public stuff.

But it doesn't mean that you can just return a single RSC from a server function. You can actually return whatever you want, so, as this slide says, the return shape is you can return as many server components from one server function as you want to. You can also combine this with plain data as you are seeing here. So, in that example, we are kicking off the loading outside of the server components as also possible, and, based on that, we render three server components in parallel, and then we return this in combination with plain data. And, on the server, it's just uniformly the plain data next to the server components, and you all render them or compose them as you please. And that pattern is usually useful when you have multiple server-rendered regions that share the same data load, or you want to invalidate them together and want to cache them uniformly.

So, if that response of server rendered UI is used by a route, we can just use the router cache the Timestack router has just like any other loader result, which is what we call route-based caching. So, if you have server-rendered UI that specifically belongs to a single route, just put it in the route loader and return it from there. So, in that example, we have get post RLC, which is our server function that defines what server component will be rendered, and you call it from a loader on the client. You can specify properties like stale time to specify how long will this data be considered fresh on the client until the loader runs again. So, in that case, we say we want to run the loader whenever stale time is exceeded, or when a new post-id value is passed in, so we just call the server function with the post param, and then we return the server component. And again, we just access the data on the client and the component, and in that case, we use the use loader data hook and you can render that.

But it doesn't mean that you can just return a single RSC from a server function. You can actually return whatever you want, so, as this slide says, the return shape is you can return as many server components from one server function as you want to. You can also combine this with plain data as you are seeing here. So, in that example, we are kicking off the loading outside of the server components as also possible, and, based on that, we render three server components in parallel, and then we return this in combination with plain data. And, on the server, it's just uniformly the plain data next to the server components, and you all render them or compose them as you please. And that pattern is usually useful when you have multiple server-rendered regions that share the same data load, or you want to invalidate them together and want to cache them uniformly.

So once the RLC value is just an async resource, the query cache doesn't need to know that the payload is a server-rendered UI. So here you see, you'll be just using a standard query key, in that case it's just two strings, RLC post preview, and then the actual post id and tab values. Oh, so let's see. Okay, I'll just pick up here. So again, you can just use TensorFlow to fetch server components as you would do for every other server loaded data, and TensorFlow doesn't need to know you have server-rendered UI, you're just putting it into the query cache as you would normally do. And in that example, you specify a query key, you specify a query function, you can use every query option like stale time as you use for every other data loading, and it will just work. And yeah, you can manually invalidate the query and then it will refetch, and then you will re-render on the client.

So in that case, the page component decides the composition on the server. It places the markdown component, which is a server component, it places the like button, and they get ClientTabs, which are client components, and their client modules will load in the browser and hydrate. So now have a look at the ClientTabs branch. The server places the comments inside of the ClientTabs, which looks like we have a server component as a child of a client component, which is React, but the server decides all that structure, so ClientTabs did not decide what it gets as a child, it's just being mandated by the server.

In the implementation, of course, the ClientTabs can say, I want to show these children, or I don't want to, but it can't select the children from the server. And that model works fine, and Start fully supports that if you want it, but it's not the only way to compose server-ended UI. We have built something that lets you invert control, because sometimes the client already owns the surrounding composition. So you have routes, layouts, surrounding interactive UI, and instead of the server owning the whole tree and marking client holes, the client owns the composition and wants to place server-rendered regions into it.

This is what we build composite components for. In this example, the route component is the composition root and it owns the layout. So it renders a toolbar which is an interactive component, and next to it, it renders a postcard region which is a server-rendered region. So this component, postcard, is a server component, it will run inside a server function, it will run load post which is a server-only function, it can use server-only dependencies, and it will not ship as to the client-side bundle. Now, the idea here is, if you want to place interactive elements inside of that server-rendered region, you can declare a slot, and in that case, that slot is called footer, and that says, in that place in the UI, I want to have an interactive component, it's called footer, and I pass a slot prop and in this case, it's an author ID, a string.

The server-rendered postcard declares the slot, and at the call side on the client, we fill that slot, so on the client-side, we say post footer, we put it into the composite component prop down here, and you can then render the whole thing, and it composes together on the client. So the client has full control over which interactive elements get put into the server-rendered regions. So this is the key thing here. You have an interactive component, and it renders a link, you can put anything inside of here, and it is connected through the composite component that we offer.

As you would expect from 10-stack, it is fully type-safe, so you define the shape of your slot, which has, in that case, it's a component with props of an author ID, and if you fail to supply up a slot prop that is the same way, then you will get a type script error. I will quickly show you how this looks like, let's see if that works, how this looks like at dev time, because now it can be a bit confusing. The composition model, let's see if that works.

Here we have our 10-stack router DevTools, and you say we are now on this route, so you can look into what does the route cache contain currently. The loaded data contains a composite source. It has these two slots declared, and it will pass these props to these slots, and you can then check whether you conform with that or not. Server components are powerful but they do not have to become the centre of the application. As we saw at the transport level, these are just data streams, server-rendered React that can move through the whole system.

If you want to inspect the data that we got from the server, you can look at our DevTools. Here we have our 10-stack router DevTools, and you say we are now on this route, so you can look into what does the route cache contain currently. The loaded data contains a composite source. It has these two slots declared, and it will pass these props to these slots, and you can then check whether you conform with that or not.

Server components are powerful but they do not have to become the centre of the application. As we saw at the transport level, these are just data streams, server-rendered React that can move through the whole system. In 10-stack start, we can reuse the existing primitives that we have, server functions, middleware, we can cache it in the router, we can cache it in query. Because you can request RSC output independently, you can choose the composition model that fits your use case.

If you want to have the server owning it, the standard use client model works, and when the client owns it, you can use composite components. So we do not need RSC to be one fixed architecture, because from our point of view, RSC is a primitive, it's not the architecture. Thank you.

Oh, yes. Oh, yes. Thank you. Great. Okay, so I just have one more slide, so let's zoom all the way back out. Server components are powerful but they do not have to become the centre of the application. As we saw at the transport level, these are just data streams, server-rendered React that can move through the whole system. In 10-stack start, we can reuse the existing primitives that we have, server functions, middleware, we can cache it in the router, we can cache it in query. Because you can request RSC output independently, you can choose the composition model that fits your use case. If you want to have the server owning it, the standard use client model works, and when the client owns it, you can use composite components. So we do not need RSC to be one fixed architecture, because from our point of view, RSC is a primitive, it's not the architecture. Thank you.

The first question I have for you is if I have a large client-side-rendered app built with Vite and React router, how challenging is it to migrate to 10-stack start? Well, it depends on which version of React router you are, probably. But overall, if you're already using Vite, you're quite at home, so since we support Vite, you should be good to go. And probably with AI being able to translate automatically between the two syntaxes, between React router and 10-stack router, it should be a breeze, I guess.

Does 10-stack have agent files or any sort of preconfigured prompts that we can try to use to convert apps? Is that in the docs anywhere? We don't have that, but we do have 10-stack intent, which is our way of declaring application-specific skills. So we might just have one for migrating to React from React router. We do have instructions to migrate from Next. So that's maybe a good idea. And can you talk about the documentation efforts? So are there any efforts being made to bring the documentation to a higher level? There are places that have coming soon in the 10-stack router docs specifically. Yeah, I mean, docs are always lagging our implementation efforts. So currently we're really pushing hard to bring start to stable, which we really want to do anytime soon now. And then documentation effort is coming along as well, nicely. Okay, that makes sense. All right. And Robert asks, what kind of support is there for micro-frontends? Does 10-stack have anything similar to Next.js zones planned? So I'm not too familiar with the zones concept, but I think it's actually just separate Next.js applications. I believe so. So I mean, you can just do this right now. So what's not right now supported really is having type-safe routing across those applications. That's something we're looking into, especially for monorepo support where each repository can bring its own routes and then you can compose them into different applications.

So we have some big companies that want to use this with huge teams, and they need that kind of separation of concerns, so we're looking into that for sure. That makes sense.

And I got another question from Anonymous. When will 10-stack start v1? What's delaying it? You kind of mentioned it, but... Yeah. I mean, it's just, it's a huge surface area, such a meta-framework. Just so many spells and whistles you need to care for. So delaying it, probably just people power. It's not, I mean, with AI we're quite speeding up a lot, but yeah, it's just so much things to do. It takes time, and you want to get it right. Yeah. I mean, we've been maturing a lot and there are not many breaking changes to be expected, maybe just like one or two minor things. So it is already quite stable. And yeah, people are betting on it already. And I guess, so right now it's RC, so that kind of means there won't really be any breaking changes. You just want to make sure that everything that is there is stable and working before it's... Yeah. I mean, there will be like two minor breaking changes, but then, yeah, nothing big. That's good to hear.

This question is, are you using RSCs on 10-stack.com, and if so, did they improve performance? Yeah, we do. I mean, this was our first playground to actually check if it makes sense to do it like we did. And it totally made sense because we just moved all the markdown rendering from the client to the server. So I mean, balance size is way lower. But of course, with RSC, you also need to look at the payload sizes you get. So when you browse around long enough on the documentation, you eventually will fetch more RSC than you would have if that renderer would have been on a client. So it's a... Yeah, there's no silver bullet, really. But if you look at our blog post where we introduce the Rake Server Components, you will see the scores that it improved. So you can check that out. That's good to know.

All right. This one is from Eddie, and the question is, with the amazing RSC implementation in 10-stack start, would you default to using RSC in new projects nowadays? And as a side note, I love that there are no use client and no use server magic strings all over the code. Yeah. So actually, I mean, that talk could have been very, very much shorter. We are just treating RSC as data. It's nothing special. And honestly, just use it if it makes sense. So in our architectural view, you should not default to it. I mean, just use what you have already been using and use server components when you want to, for example, improve client side rendering performance, bundle size, but it's not the default, definitely. Would it be accurate to say that 10-stack start kind of gives you server side rendering already, so you kind of get the benefit of what people were reaching for React server components out of the box with 10-stack start? Is that accurate to say? Yeah. I mean, I tried to explain that RSC is maybe a pre-processing step for SSR, but not a mandatory one. So you can have fully streaming HTML rendering in 10-stack start from the get-go. So you don't need RSC for that. You can render suspense, you can do all of that. It's not necessary. It's good to hear.

What are the advantages and disadvantages of the 10-stack RSC compared to Next.js' implementation? Well, you can use it or you don't have to. So I'd say being able to choose is always an upside. The downside is, of course, that some people might say you need to learn some new APIs, you need to use render server component if you want to render a server component. But I'd say in today's age of AI coding, you're probably not even writing it yourself, so the verbosity is probably okay. So yeah, but sure, it's a different API that you might need to learn, and the concept you need to understand. But we say it's worth it that you don't have to default your whole app to the RSC model. Especially since we're targeting client-first applications, because that's where it makes sense to actually have React and interactivity. So if you're just doing static sites and pre-rendered stuff, maybe you shouldn't be using React at all. That makes sense.

That makes sense. And I guess I read the launch blog post for RSCs in 10-stack, and you guys kind of took a stance in terms of it being one-way, right? Like the server components stream from the server to the client, and it's not bidirectional like it would be with Next.js. Would you say that's a disadvantage or an advantage in terms of the implementation compared to Next.js? Yeah, I mean, the term RSC is again a bit overloaded. So we say RSC is the primitive for UI that is rendered on the server. But it's somehow conflated with the server actions or a function thingy that they also have. And we said we're not doing that. So we are not introducing new servers, so we're not supporting React server functions, React server actions, whatever they're called nowadays, because the protocol just has been proven very insecure in the past, which is saying we're not supporting that. I mean, theoretically, people could use a middleware and build it on top of that if they really, really wanted to. But that's just what we're not doing. So yeah, that's kind of a disadvantage. But I think the idea of that full stack component where you just install an npm package that has client components and all that stuff, and also server actions, I haven't seen that really happening. And also maybe it's a bit scary that some npm package can just spin up a server endpoint that you don't control. True. So, yeah. Yeah, I mean, I honestly see that as an advantage, because there's less surface area for getting things wrong and you have more control over where things live.

All right. Time for maybe one or two more questions. This next one. Do you have any advice on how to component test when using TanStack router? The docs are not great for this. Yeah. I mean, component testing, you can... It depends on whether... When you define the component in line in our create file route thing, I accept that the docs are not great for this. We are working on testing utilities where you can spin up a mock router and just set it into a state without using play write. But for unit tests... I see. Yeah. But if you're just using exported components, you can just component test whatever you want. I mean, you need to mock the router, and we're adding utilities for that, but later to come. Okay. Good to hear. That's about all the time we have, but if you have more questions for Manuel, he'll be over there at the Q&A section. But thank you so much. Thanks.