React Server Components: Concepts and Patterns

React Server Components (RSC) are the culmination of a long and wide-ranging architectural overhaul of React itself. This change invites a rethink of your best practices and unlocks an immense number of optimizations that weren’t otherwise possible.

From bundling size to safer requests, your apps can become much better for it and the end-user experience (UX) will benefit greatly. But in order to leverage these benefits, you need to understand RSC.

RSC consists of server components, which execute on the server side, and client components, which execute on the client side. The next section explains more about these and the difference between them.

Client-side rendering vs. server-side rendering

Client-side rendering is just that — often the server sends the browser nothing but a minimal HTML placeholder page and references to scripts, and the browser then downloads all the JavaScript libraries (the frontend framework and your application bundle). It then initializes them on the page and builds the user interface as you designed it. The tradeoff is slower page rendering vs. faster in-page navigation (once the page is loaded). Be aware that client-side rendering is performed by the client component side of React Server Components and does not execute on the server side.

Server-side rendering is performed by the server components side of React Server Components and is like using the frontend renderer as a template engine. All non-interactive components are rendered on the server, sent to the browser, and then “hydrated” to provide interactivity. The benefit is faster loading time. There are a number of different approaches to this, such as static site generation and incremental static regeneration.

React Server Components use server-side rendering to optimize the rendering process and only send the necessary data to the client, avoiding hydration. The net effect is faster load times, immediately available content, and less JavaScript to execute, which will all benefit your SEO because search engines don’t need to work so hard to index your pages.

The road to server components

The architecture shift began years ago with Concurrent React. If you’ve been around the React ecosystem for a while, chances are you’ve heard of Suspense. React Suspense enables developers to create slots in the rendering tree, which will be filled by asynchronous components once data is available for them. Unlocking the powers of an asynchronous rendering tree were fundamental to this next evolution of React’s component-based architecture.

The above block will render “Loading…”, which the user sees until  ServerComponent finishes fetching data and rendering on the server. At that point, React will stream the finished ServerComponent to the client and patch it into the right slot in the rendering tree. Finally, there will be a re-render where React replaces the fallback text or component with the contents of  <ServerComponent />.

What are React Server Components?

React Server Components can be explained briefly with a short example.

The function above has two key elements:

1. The function logic (represented by the comment block) executes entirely on the server. You would use this to populate the values that would render in the returned JSX.

2. React serializes the returned JSX and sends it to the client. In this case, there is no hydration required because there is no interactivity needing JavaScript, so it will be rendered exactly as sent.

As we said above, React Server Components can be either server components or client components. By default, all React Server Components are assumed to be server components unless they are preceded with the ”use client”; string at the top of their file. This means anything not returned by the component’s renderer, like unused branches of conditional statements, will not get to the client, potentially resulting in a lot less code for most apps. Nevertheless, the mental model around RSC is different.

Let’s illustrate this with a (slightly contrived) example. The following component would probably cause unnecessary memory consumption for client-components, but if it were a server-component, it could cause bloat to be sent across the wire:

Note that each component is sending the entire list across the server/client connection. For a list with ten items, this means those ten items all get sent across the wire ten times, plus the one time the data is being rendered. While this is a contrived example, realise that many real-world SPAs (single-page applications) do follow a similar pattern: to reorder items in a list, for example.

This means that server-rendered components and client-rendered components behave completely differently with regard to the serialization boundary.

The serialization boundary

To transmit data between server and client via HTTP, the framework first needs to serialize the data. React uses the popular JSON format for this. The point where data is serialized and deserialized is called the serialization boundary.

Serialized data cannot contain functions, date objects, non-enumerables, or circular references.

When doing server-side rendering (SSR) on React, either Remix’s loader and action functions or Next.js’s getStaticProps and getServerSideProps were previously used to cross the serialization boundary. 

In React Server Components, the serialization boundary functions like a fence around our components, encapsulating data within them. While fetching data is efficient (discussed below), passing props to children should be avoided unless absolutely necessary, because they must be serialized and sent over the network.

This table highlights the differences between using the traditional method, in frameworks like Next.js with getStaticProps, vs. React Server Components.

Data fetching with React Server Components

Based on best practices for the web, React also needed a solution for data fetching on the server side for RSC to be usable. Without a caching layer, requests would be duplicated and this would be a non-starter for most apps.

If you've worked with pure React (without a fullstack framework around it), chances are you’re familiar with the approach below for filling a component with data:

Depending on your exposure level to React, you may think this code is straightforward. However, let’s walk through what’s going on:

1. getDog defined within the module scope to fetch a random dog image from an API.

2. We create an empty state for the first render, where dog is an empty string.

3. React initially renders with a broken <img /> tag (because an empty src attribute is not valid HTML).

4. useEffect kicks in asynchronously. It declares goFetch and calls it. This only happens once because useEffect’s dependency array is empty: there are no triggers to restart this side effect.

5. As soon as the response is fetched and parsed, it then calls setDog — adding a new state and storing the fetched image in the dog state variable.

6. The new state triggers a re-render and the image is finally fetched, parsed, and rendered by the DOM.

The six steps involved in getting that image rendered show that this is not a straightforward process; it’s just the one we’re used to. React Server Components significantly reduce the mental overload involved in getting this done.

To achieve this simplification, the React team changed the fetch API so it could track requests firing from different components during the same render process. This means that requests are fired only once for a given render.

Here’s how the dog fetcher component from earlier would look with Server Components.

Here is what’s going on in this asynchronous JavaScript and React JSX:

1. An asynchronous fetch request is fired, blocking function execution.

2. The response arrives and is parsed from JSON, returning an object with a message key, which is a string containing the URL of a dog photo, that is then destructured and aliased to dog.

3. The img element uses dog as its source url.

That component is shipped as static HTML to the browser and rendered immediately on arrival.

React Server Components have made React more than a “UI rendering library” and more opinionated than it once was. Using React Server Components implies that in architecting a caching layer, caching requires a routing system, and ideally leverages this with prefetching and preloading of resources to maximize delivery performance. This is why a production-ready implementation of RSC outside of the context of a framework is difficult.

Next.js is the main framework with full support for React Server Components ready for production use because it has integration with the App Router built in. If you were to build React server-side without a framework, you would need to set up the server to host the application and import the server-side rendering functions, ensure a clear separation between server and client components and manage the serialization between them, and finally hydrate. For all of this, you would have to use React Express, ReactDOMServer, and ReactDOM, and a number of build tools.

Patterns to combine server and client components

In the following sections, we will look at various patterns for using React’s server and client components that can already be used in production as well as some more experimental APIs that are close to general availability.

Next.js: App directory routing

In order to give React Server Components first-class support, Next.js completely re-engineered its router. Routing is a big piece of any fullstack framework, but by re-engineering it, Next.js was also able to leverage server components to offer big improvements in UX (user experience) and DX (developer experience).

It’s possible to leverage the filesystem-based routing to establish error boundaries (showing the default error page instead of an error) and suspense boundaries (placeholder content during lazy loading) for an entire route. Defining those is just the same as creating any other component, except that they obey a file-naming convention.

Within each page, it’s also possible to create more granular boundaries and pass the fallback components as you would in any other React application.

Optimizing data fetching with React Server Components

Thanks to the asynchronous nature of RSC, it’s possible to call promises from within its rendering logic. This includes fetching data with much less boilerplate, as described above. Here’s an example of some code that could be improved:

In this case, the page fetches data with two different methods: getAuthor and getAuthorPosts, but in a very procedural way. First it calls getAuthor and waits for the response, then it calls getAuthorPosts and waits for the response, then it can finally render the component with all the data.

This isn’t the most efficient way to fetch from multiple endpoints and it’s possible to go further and use different patterns that will increase the performance and UX of your apps. Firing both requests in parallel and awaiting the result of both will yield the same results but in a more efficient way, as both requests are in flight simultaneously.

Sometimes not all the requests are fundamental for the user experience. In such cases, it is possible to allow rendering to happen as early as possible and instruct the framework to stream down data as soon as it is ready.

In the above snippet, the renderer will wait for authorData while postsData will be passed down as a promise, before forwarding the promise into a suspense boundary (lazy-loading wrapper) that will first load a fallback component in case the data isn’t made available by DOM hydration.

Handling interactivity

React Hooks aren’t executed on the server. No exceptions. In SSR, the Node.js (server-side) runtime will skip every hook and, once the client component runs in the browser where hydration kicks in, the client-side logic gets run. This is why a lot of libraries and frameworks create workarounds in order to provide pre-filled data to the static markup.

Server components can’t do this because their logic is not shipped to the client. Though they are hydrated, some of the conditions and a lot of the code stays on the server. Therefore, it is not, and probably will never be, possible to run Hooks on RSC. Also, server components never re-render. They run once to generate the UI, then transmit that to the client. There is no lifecycle to cause a refresh of the UI server-side.

As React becomes a fullstack framework, apps split into two different bundles: one for the server and one for the client. And as components have different APIs available to them, depending on the runtime they render on, you need to help your framework (and compiler) understand which bundle each component belongs to.

Remember, by default, React components are treated as server components in a React Server Components setup. To add interactivity to a component, you need to designate it as a client component by including the “use client” directive as the first line of the file.

One important side effect of using React Server Components is that when you use a client component, all of its child components automatically become client components too. So, it’s best to keep interactive elements (like buttons or form fields) at the edges (or “leaves”) of the component tree. This way, server components handle most of the logic and data fetching, while the child components handle user interactions.

Handling data mutations in React Server Components

To implement and push mutations from any component — server or client — most React-based frameworks have an implementation of server actions. These are special endpoints designated to respond to  POST,  PUT,  PATCH, or DELETE actions being fired from a client. Their integration interface is the <form> element (even if there’s some syntactic sugar involved) or its friends <button> and <input>.

Frameworks like Remix and Next.js work similarly, but have different implementations and tradeoffs. They are intended to address pending UI states and optimistic transitions (allowing the UI to behave as though the mutation has succeeded before receiving the response). Next.js’s server actions are experimental, while Remix’s are completely stable and already work in both server and client components.

For Next.js, a server action can be declared as its own module and requires a "use server" directive at the top of the file. With form components as the base implementation, not only is it possible to give RSC a way of providing interactivity, but it’s also aligned with progressive enhancement. Data mutations (e.g., form submissions) can now happen directly on the server, reducing your dependency on JavaScript in the browser.

Concerns about React Server Components

Even though React Server Components make it more difficult to send bloated bundles to the client, you must still exercise caution when creating your components, because stuffing excessive dependencies or badly placed logic along with your interactivity code can still impact performance. Here are some concerns to be aware of when building your RSCs:

• Improper use of client components: Client components are necessary to make your app interactive, but overuse can negate the benefits of server-side rendering. Ensure that only components needed on the client side are rendered there.

• Shared dependencies: If server and client components share large dependencies, those dependencies can end up in the client bundle. To avoid this, try to avoid importing libraries unnecessarily into your client components.

• Granularity of components: Breaking your app into too many small components, especially if they frequently switch between server and client components, can increase overhead and network traffic. While breaking your interface into components is a good approach, too many components can actually increase the network traffic, increase render time, and hit the performance of your app.

• Lazy loading: Failing to implement lazy loading for client components or resources can result in users downloading more code upfront than needed. Your page will render faster the less it has to download, so even with the benefit of RSCs, try to lazy load anything not required up front.

When to use React Server Components

You should aim to minimize the number of client components in your application, keeping only those that require state or interactivity. Components like forms, buttons, or any UI elements handling user interactions need to be client components.

RSC can only ship resources to the client that are used during rendering. Any rendering that can be done server-side to avoid the client browser spending time building the interface, or fetching information which is closer to the server, should be moved to server components, for example:

• Data-heavy components: Components that fetch or process large amounts of data (e.g., database queries or API calls) should be server components, to avoid needing to send this data to the client.

• Non-interactive components: Components that do not require interactivity (e.g., rendering static data, layouts, or static lists) are good candidates for server components.

• Components that benefit from security or server-side logic: Components that render sensitive or user-specific data (e.g., admin dashboards, user profiles) are better handled on the server to avoid exposing sensitive information to the client.

• Large components or assets: Components with large bundles or heavy computations benefit from being rendered server-side to avoid bloating the client bundle.

Of course, you should also use RSC when your page needs to rank higher in search results to boost your SEO and contains plenty of content which can be generated server-side.

React Server Components and their implications are a big step toward a better, more performant, and higher quality web. While they may not be suited to every React app, and it’s important to evaluate the tradeoffs for your codebase, replacing a regular client component with a server component can introduce performance improvements, increased SEO, and an overall better architecture to your frontend solution.

React Server Components allow you to fetch Contentful data directly on the server, ensuring efficient delivery of your CMS content without the overhead of additional client-side JavaScript. Get started with Contentful and build a web app.

Start building

Sign up for a free Contentful account

Use your favorite tech stack, language, and framework of your choice.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.