Server Components

React Server Components represent an architectural evolution in user interface development, enabling components to execute and render entirely on the server prior to being transmitted to the client. These components operate in a distinct execution environment, decoupled from the browser and the client-side JavaScript runtime, and can be invoked either statically at build time or dynamically on each request via a server process ^[1][2].

Here is a simple example of a Server Component ^[3]:

import db from 'imaginary-db';

async function Homepage() {
  const link = db.connect('localhost', 'root', 'passw0rd');
  const data = await db.query(link, 'SELECT * FROM products');

  return (
    <>
      < h1>Trending Products< /h1>
      {data.map((item) => (
        < article key={item.id}>
          < h2>{item.title}< /h2>
          < p>{item.description}</p>
        < /article>
      ))}
    < />
  );
}

export default Homepage;

This component runs on the server and is serialized into the React Server Component Payload, which the client uses to render and hydrate the UI. In this context, hydrating the UI refers to the process where the client-side JavaScript takes over the static HTML sent from the server and attaches event handlers, state, and interactivity. This allows the page to become fully interactive without needing to re-render everything from scratch, effectively turning static markup into a live React application in the browser.

Rendering UI on the server introduces several computational and architectural benefits. Data fetching is colocated with the server environment, reducing round-trip latency and allowing more direct access to backend resources. Because the logic is executed in a secure, non-public context, sensitive data such as API credentials or tokens remains isolated from the client. Moreover, server-rendered output is cacheable, permitting reuse across multiple requests and users, which reduces redundant computation and enhances scalability.

The client-side JavaScript footprint is significantly reduced when non-interactive UI elements are rendered on the server. This optimization minimizes the amount of code sent to and executed by the browser, improving performance metrics such as First Contentful Paint (FCP) and Time to Interactive (TTI), particularly in constrained network or device conditions ^[2]. Furthermore, since the server produces complete HTML, pages are immediately indexable by search engines and interpretable by bots for social media link previews.

Streaming capabilities further refine this model by enabling the incremental transmission of rendered content. The server can begin sending portions of the UI as soon as they are ready, without blocking on the completion of the entire render tree. This facilitates progressive hydration and allows users to perceive and interact with content sooner, even under high-latency conditions.

React Server Components are designed to interoperate with client components, supporting selective interactivity and asynchronous operations as needed. This hybrid approach allows developers to allocate rendering responsibilities according to performance, security, and architectural constraints.

The Rendering Lifecycle of Server Components

Server Components are rendered through a multi-phase process that begins entirely on the server. React’s internal APIs coordinate the rendering pipeline by partitioning the work into discrete units based on route segments and Suspense boundaries. Each unit undergoes a two-stage transformation.

First, the Server Components are rendered into a structured binary data format known as the React Server Component Payload, or RSC Payload ^[4][2]. This payload represents the fully evaluated output of the Server Component tree.

In the second stage, this payload is combined with instructions for rendering Client Components and used to produce the initial HTML response. When the client receives this HTML, it is immediately displayed as a static, non-interactive representation of the page to minimize time-to-content.

Concurrently, the RSC Payload is parsed in the browser to reconcile the server-rendered component tree with the client’s runtime environment. React uses this payload to insert Client Components in the correct locations and apply any necessary updates to the DOM. JavaScript bundles corresponding to the Client Components are then loaded and hydrated, activating event handlers and restoring full interactivity ^[2].

The RSC Payload itself is a serialized, compact binary format that encodes the structure and content of the rendered Server Components ^[4]. It includes the fully resolved output of each Server Component, embedded references to Client Components indicating where they should be rendered, and the props required for their execution. This mechanism allows the client to precisely reconstruct the intended UI without re-fetching or re-evaluating server-side logic.

Server Functions

In React's architecture, Client Components are components that execute in the browser. They are the default and most common way of developing frontend user interfaces, not just in React but across modern frameworks. Client Components handle rendering, manage local state, respond to user interactions, and interact with browser APIs. They define how a user interface looks and behaves in response to user input, and they operate within the client-side JavaScript environment.

Server Functions extend this model by allowing Client Components to invoke asynchronous functions that execute on the server. These functions are defined using the "use server" directive, which marks them to be run in the server environment. When a Client Component calls a Server Function, React transmits a request to the server to execute the function, and then returns the result to the client.

Server Functions may be defined inside Server Components and passed to Client Components as props, or imported directly into Client Components. This model enables seamless client-server communication without exposing sensitive logic or credentials to the browser ^[5].

Server Functions can be used in many contexts: form submissions, button clicks, effect hooks, or third-party libraries ^[5]. When invoked through a form’s action attribute, React handles the form submission natively, even before hydration completes. This enables progressive enhancement, ensuring that the form behaves correctly even if JavaScript hasn’t loaded yet.

Because these functions run exclusively on the server, they provide a secure way to mutate data, such as performing database operations, without shipping sensitive logic to the client. React integrates Server Functions deeply with its rendering and caching mechanisms, allowing efficient server-side updates that return both UI and data in a single roundtrip.

Note: Until September 2024, all Server Functions were referred to as “Server Actions.” Today, the terminology is more precise: a Server Function becomes a Server Action only when it is used in the context of a form action prop or is invoked inside an action. Not all Server Functions are Server Actions, and the updated naming reflects the fact that Server Functions serve broader purposes across the React architecture ^[6].

Example of a Server Function

The following example^[6] demonstrates a Client Component calling a Server Action using React’s "use server" directive, which enables a seamless invocation of server-side logic directly from the client.

The first file defines the Server Function. It is marked with the 'use server' directive, which instructs React to treat all exports in the module as functions that should only run on the server. In this case, the function performs a database mutation:

// actions.ts
'use server';

export async function createNote() {
  await db.notes.create();
}

In the second file, a Client Component imports and invokes that Server Function. The "use client" directive marks this component as running in the browser. Although createNote is called like a regular function, React intercepts the call and sends a request to the server to execute it. This behavior is what qualifies createNote as a Server Action in this specific usage context.

// EmptyNote.tsx
'use client';

import { createNote } from './actions';

export default function EmptyNote() {
  console.log(createNote);
  // {$$typeof: Symbol.for("react.server.reference"), $$id: 'createNote'}

  return (
    < button onClick={() => createNote()}>
      Create Note
    < /button>
  );
}

This model allows interactive UI, built using Client Components (the standard development model in all frontend frameworks), to offload logic securely to the server. React handles serialization, transport, and invocation behind the scenes, allowing developers to structure their application code by responsibility and execution context.