header image

Author: tannerlinsley

media/brand.sketch

@@ -6,9 +6,11 @@ authors:
   - Manuel Schiller
 ---
 
+![What If RSCs Were Actually Components?](/blog-assets/tanstack-start-rsc/header.jpg)
+
 React Server Components are a genuine leap for React. They reduce bundle size, stream UI as it resolves, and move work off the client.
 
-But the current model comes with a tradeoff: **the server owns the component tree**.  
+But the way RSCs have been implemented so far comes with a tradeoff: **the server owns the component tree**.  
 Your client code opts into interactivity with `'use client'`. **Composition flows one direction**—server decides, client receives. The React model you know—props, context, bidirectional composition—gets fragmented across environments.
 
 What if it didn't have to?
@@ -19,9 +21,25 @@ That's what we built in **TanStack Start**.
 
 ---
 
+## Why RSCs Matter
+
+Before diving into the model, it's worth understanding when server components shine:
+
+- **Heavy dependencies stay on the server.** Markdown parsers, syntax highlighters, date formatting libraries—these can add hundreds of KB to your bundle. With RSCs, that code runs on the server and only the rendered output ships to the client.
+
+- **Colocated data fetching.** TanStack Router already eliminates waterfalls by parallelizing route loaders. RSCs offer a different ergonomic: awaiting data directly in the component that renders it, which can be convenient for static or slow-changing content.
+
+- **Sensitive logic stays secure.** API keys, database queries, business logic—none of it reaches the client bundle.
+
+- **Streaming for perceived performance.** Instead of waiting for all data before showing anything, RSCs stream UI progressively. Users see content immediately while slower parts load in the background.
+
+RSCs aren't about replacing client interactivity—they're about choosing where work happens. **The question is: who controls that choice?**
+
+---
+
 ## The One-Way Problem
 
-In the traditional RSC model, the server is the only place that decides what interactive elements to render.
+In existing RSC implementations, the server is the only place that decides what interactive elements to render.
 
 Need a `<Link>` with prefetching? **Server** renders it with `'use client'`.  
 Need a dashboard widget? Server renders the boundary, marks it client. **The server is always the decision-maker. The client is always the recipient.**
@@ -39,7 +57,7 @@ In the traditional model, you'd create a new client component, a new file, a new
 
 **Server components can render interactive elements directly**—`<Link>`, `<Button>`, anything marked `'use client'`. That part works the same.
 
-But they can also **declare slots**—regions where the client decides what to render. Not by creating new components or files, but through plain props: children, render functions, whatever pattern you already use.
+But they can also **declare slots**—regions where the client decides what to render. Not by creating new components or files, but through plain props: children, render functions, whatever pattern you already use. These aren't special APIs—`renderActions` in the example below is just a prop name we chose. You can name your render props anything you want.
 
 ```tsx
 // Server
@@ -59,7 +77,9 @@ const getPost = createServerFn().handler(async ({ data }) => {
         <p>{post.body}</p>
 
         {/* Server renders this directly—it's interactive via 'use client' */}
-        <Link to={`/posts/${post.nextPostId}`}>Next Post</Link>
+        <Link to="/posts/$postId" params={{ postId: post.nextPostId }}>
+          Next Post
+        </Link>
 
         {/* Server defers this to the client */}
         <footer>
@@ -108,7 +128,11 @@ That's inversion of control.
 
 Here's the shift: in TanStack Start, **server components aren't a paradigm**. They're a _primitive_—a serialization format that flows through your existing architecture.
 
-When `createServerFn` returns a server component, that component is a **stream**. Streams are universal. They work with:
+When `createServerFn` returns a server component, that component is a **stream**. This means you don't have to wait for the entire component to finish rendering before sending HTML to the client. Parts of the UI can render immediately while slower async work (database queries, API calls) resolves in the background. The client sees a Suspense fallback, then the final content streams in when ready—no full page reload, no blocking.
+
+This works for SSR (streaming HTML during initial page load) and for client-side fetches (streaming RSC payloads during navigation or data refetches).
+
+Streams are universal. They work with:
 
 - **TanStack Router** → Load server components in route loaders, stream them during navigation
 - **TanStack Query** → Cache server components, refetch in the background, deduplicate requests
@@ -155,6 +179,8 @@ Every property access and function call is tracked:
 - `props.children` → serialized as a slot placeholder
 - `props.renderActions({ postId, authorId })` → serialized with the arguments attached
 
+You can destructure props normally—`({ children, renderActions })` works just as well as `props.children`. The proxy handles both patterns.
+
 **Over the wire, it's a React element stream** with embedded placeholders. On the client:
 
 1. The stream decodes into a React element tree
@@ -235,7 +261,7 @@ Because it's not about client or server.
 
 This is the first experimental release of RSCs in TanStack Start. A few things to know:
 
-**React's Flight serializer** — This release uses React's native RSC Flight protocol for serialization. That means TanStack Start's usual Seroval-based serialization isn't available within server components for now. Standard JavaScript primitives, Dates, and React elements serialize fine. Custom Seroval plugins and extended types will come in a future release as we unify the serialization layers.
+**React's Flight serializer** — This release uses React's native RSC Flight protocol for serialization. That means TanStack Start's usual serialization features aren't available within server components for now. Standard JavaScript primitives, Dates, and React elements serialize fine. Custom serialization plugins and extended types will come in a future release as we unify the serialization layers.
 
 **API surface** — The `createServerComponent` API and slot patterns shown here are stable in design but may see refinements based on feedback. We're shipping early to learn from real usage.
 
@@ -267,9 +293,42 @@ No. RSCs are entirely opt-in. You can build fully client-side SPAs with TanStack
 
 TanStack Start's RSC implementation builds on React's Flight protocol and works with React 19. Server Actions are a separate primitive—`createServerFn` serves a similar purpose but integrates with TanStack's middleware, validation, and caching model. We're watching the Server Actions API and will align where it makes sense.
 
-### When will Seroval serialization work inside RSCs?
+### When will TanStack Start's full serialization work inside RSCs?
+
+It's on the roadmap. The current release uses React's Flight serializer directly, which handles the core use cases. Unifying with TanStack Start's serializer for custom types, extended serialization, and tighter TanStack DB integration is planned for a future release.
+
+### Can I define my component outside of `createServerComponent`?
+
+Yes. `createServerComponent` initiates the RSC stream generation, but your component can be defined separately and invoked inside:
+
+```tsx
+function PostArticle({ post, children, renderActions }) {
+  return (
+    <article>
+      <h1>{post.title}</h1>
+      {renderActions?.({ postId: post.id })}
+      {children}
+    </article>
+  )
+}
+
+const getPost = createServerFn().handler(async ({ data }) => {
+  const post = await db.posts.get(data.postId)
+  return createServerComponent((props) => (
+    <PostArticle post={post} {...props} />
+  ))
+})
+```
+
+### Can I return raw JSX instead of using `createServerComponent`?
+
+Not currently. Server functions that return UI must wrap it in `createServerComponent`. This is what enables the streaming, slot handling, and client rehydration. Plain JSX returned from a server function won't have the RSC serialization behavior.
+
+### Do `cloneElement` and React Context work with server component children?
+
+**`cloneElement`**: This won't work as you might expect. When children are passed from client to server, they're serialized as slot placeholders—not actual React elements the server can manipulate. The server can't inspect or clone client-provided children.
 
-It's on the roadmap. The current release uses React's Flight serializer directly, which handles the core use cases. Unifying with Seroval for custom types, extended serialization, and tighter TanStack DB integration is planned for a future release.
+**React Context**: Context providers rendered by the server component _will_ wrap client children. If your server component renders `<ThemeProvider value="dark">{children}</ThemeProvider>`, the client children can consume that context. However, the context must be defined in a way that works across the server/client boundary (typically with `'use client'` on the provider component).
 
 ---
 

public/blog-assets/tanstack-start-rsc/header.jpg

@@ -128,7 +128,7 @@ function DocsMenuStrip({
             <div
               key={index}
               className={twMerge(
-                'flex-1 min-h-[4px] max-h-[9px] rounded-sm',
+                'flex-1 min-h-[4px] max-h-[9px] min-w-[20px] rounded-sm',
                 item.isSection
                   ? 'w-full bg-current opacity-15'
                   : isActive