This article discusses [React Server Components](https://react.dev/reference/rsc/server-components) (RSC) in [TanStack Start](https://tanstack.com/start/latest), proposing an approach that differs from and, arguably, improves upon the RSC implementation seen in Next.js. Rather than offering a direct comparison, the article introduces the concept from the ground up, as realized in TanStack.
**What are React Server Components:**
RSCs are standard React components that run exclusively on the server, leading to major differences. They can be asynchronous, accessing data directly within the component. This means they can use `await` for any data from a third-party API or a direct database call, sidestepping the need for client-side connections or exposing sensitive information like connection strings.
RSCs never run on the client, so their code isn’t shipped client-side. They deliver only the final rendered markup to client bundles. Due to their server-side existence, RSCs can’t have state or user interactions and cannot use hooks like `useState`, nor event handlers like onClick. To integrate interactivity, it’s possible to combine them with client components.
**What RSC is Not:**
RSC is not aimed at simplifying data loading—TanStack Start already addresses this with efficient data-loading options through nested, isomorphic loaders. These loaders operate on the server initially and on the client subsequently, integrating with `react-query` for fine-grained data management.
Moreover, RSC does not serve content rendering. Both TanStack Start and Next.js already handle server-side rendering. In contrast, RSCs strictly render on the server.
**Where RSC Shines:**
Server-side rendering with RSCs helps reduce client bundles by excluding the code required to render content. They are especially beneficial for components with minimal client interactivity. An example from TanStack’s blog showcases using RSCs to manage content with code samples, offloading parsing, styling, and formatting to the server, thereby reducing client-side libraries. Another potential is managing conditional renders based on user types without bloating the client component bundle.
**Getting Started:**
Consult TanStack’s [setup documentation](https://tanstack.com/start/v0/docs/framework/react/guide/server-components#setup) for Vite, and view the corresponding [GitHub repo](https://github.com/arackaf/tanstack-start-rsc-blog-post).
**The Normal Way:**
TanStack developers typically render UI through non-RSC components, using loaders for initial render data and `Suspense` tags for pending states.
**The Non-RSC Payload:**
A setup ensures that Lucide React’s entire package gets bundled, simulating a complex client component structure with a 308 KB production JavaScript payload.
**Rendering with RSC:**
Creating a simple RSC involves rendering an application shell component without props, illustrating the method of displaying an RSC stream via TanStack’s API by leveraging `renderServerComponent`.
**Rendering Interactive Content:**
While components can be rendered directly from RSC using the “use client” pragma, exploring props allows alternative content handling flexibility, albeit not ordinary prop-passing as before rendering occurs server-side.
**Passing Props to our RSC:**
Props in RSC are usually client components. Using `createCompositeComponent` defines such props, enabling flexible rendering in TanStack’s methodology.
**Loading Data in RSC:**
RSCs can fetch data directly and use `Suspense` to manage incomplete data states, creating seamless server-rendered content.
**The Total Savings with RSC:**
Switching to RSC dropped client-side JavaScript payloads from 308KB to 203KB, exemplifying its potential benefit in reducing load sizes.
**When to Use RSC:**
RSCs are not universally essential. They shine with large, non-interactive component trees benefiting from deferred client-side costs. Assess project structure and requirements for optimal deployment.
**Concluding Thoughts:**
TanStack’s RSC implementation aligns with needs for efficient, client-lean rendering. By keeping unnecessary operations server-side, performance improves when it would otherwise be burdensome client-side.