React's server components haven't received the warmest welcome into the ecosystem, largely because of the learning curve required to adapt to the new concepts. This article aims to walk the average React user through what to expect when working with React Server components in some of the newer meta frameworks, such as Next.js.

Setting The Context

Let's start with a simple example. If you have experience working with "traditional" React, you've probably seen or written something like this at some point.

import React, { useEffect, useState } from 'react';

const App = () => {
  const [data, setData] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch('https://api.example.com/data');
      const result = await response.json();
      setData(result);
    };

    fetchData();
  }, []);

  return (
    <div>
      <h1>Fetched Data</h1>
      {data ? <pre>{JSON.stringify(data, null, 2)}</pre> : <p>Loading...</p>}
    </div>
  );
};

export default App;

You may be more familiar with the class component variation if you have worked with React in a legacy codebase. You can also use class components with server components if that's your thing!

The code in the image above would work as expected in a traditional client-side React application. However, it would crash in a server component because the server doesn't have direct access to the web browser. It's important to note that many of the React behaviors we're used to reaching for exist as extensions of a browser-based API in the React-DOM package.

When working with server components in React, we have to adopt a new mental model of client-side code. It's different, but it's easy. Consider that the traditional server-side rendered limitations will still exist in React.

It's helpful to think of server components like a template language. Client components are the same as they've always been. For server components, we can pass props and compile JSX asynchronously. Client components can still utilize the same stateful and browser-side behaviors we've always known in React.

How to Determine If Client or Server Component

Remember the "use strict" directive we used to have to add to the top of our JS documents ourselves? Client components use the same string-at-the-top-of-the-file convention, specifically detonated by the "use client" directive, a React standard. It looks like this:

"use client"

import React, { useEffect, useState } from 'react'
// ...

In Next.js, all components are rendered on the server by default unless you've explicitly opted out via the "use client" directive. If you don't have the "use client" directive, Next.js will treat the component as a server component.

What Does Server-Side Rendered Look Like?

Have you ever worked with Express.js and Handlebars? Or Go and its template system built into the standard library. Check out this really simple Node.js application serving an HTML file over an Express.js server.

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
    const htmlString = `
        <!DOCTYPE html>
        <html lang="en">
        <head>
            <meta charset="UTF-8">
            <meta name="viewport" content="width=device-width, initial-scale=1.0">
            <title>Simple Express API</title>
        </head>
        <body>
            <h1>Hello, World!</h1>
            <p>This is a simple HTML string served by Express.</p>
        </body>
        </html>
    `
    res.send(htmlString)
})

app.listen(port, () => {
    console.log(`Server is running at http://localhost:${port}`)
})

Notice how the Node.js application above depicts an HTML file created with a simple string. When we launch that Express.js server, it's actually rendering an HTML page in the browser. We can imagine a similar concept for the frameworks and technologies mentioned above. So, what's the relation to Server components? They all start at the server and end up on the client (Browser).

With server components, we could render the same "Hello, World" from the server with React components. From an abstract point of view, we now have direct access to React from the server. That's huge. React developers can now completely remove unnecessary loading states, submit forms directly from the server, capture query parameters, and authenticate users before showing anything, to name a few explicit benefits.

Example of a React Server Component

So what the heck does a React Server Component even look like? Well, not much different than a client-side React component. Let's rewrite the client component we created above as a server component.

const App = async () => {
  const response = await fetch('https://api.example.com/data')
  const data = await response.json()

  return (
    <div>
      <h1>Fetched Data</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  )
}

export default App

We're essentially doing the same thing. Keen eyes may have noticed there is no loading state; that's a pivotal aspect of server components. The example above retrieves the data asynchronously and the JSX is painted in the React tree before the user sees anything. Basically, there's no need for the loading state.

With server components, we can retrieve data from an external source, like a database, and then pass that data into some JSX. Boom, just like that, we have a web page. But the reality is often more complex, and there are many times when you can't get away from client-side behaviors (especially if you are using React, a framework designed for interactivity).

How to useEffect with React Server Components

To utilize the useEffect hook with React server components, you must create two files: one for your server component and one for your client component. (Yes, it has to be two separate files.) Like the server component example we defined above, we can asynchronously fetch data from an external source and then pass it to a client component as a prop, where it will be fully accessible to the client once the page has hydrated.

In practice, we're looking at something like this:

// MyServerComponent.jsx

import MyClientComponent from "@/components/MyClientComponent"

const MyServerComponent = async () => {
  const response = await fetch('https://api.example.com/data')
  const data = await response.json()

  return (
    <div>
      <MyClientComponent data={data} />
    </div>
  )
}

export default MyServerComponent

Our client component can quite literally be anything we would have used in a traditional React app.

// MyClientComponent.jsx

import React, {useState, useEffect} from 'react'

const MyClientComponent = ({ data }) => {

  // client side code here

  return (
    <div>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  )
}

export default MyClientComponent

Behind the Scenes, React automatically serializes this data into JSON format, which is then embedded within the HTML sent to the browser as props for the client component. So, during the initial client-side render, the data is deserialized, but the client component doesn't have access to any of the browser-specific APIs, nor does it have the ability to manage its state or effects until the hydration process has been completed.

The React Hydration Process

You've probably heard of the term hydration in React. (The React team deprecated the hydrate API and transitioned to hydrateRoot in React 18.) The process makes the client-side UI interactive after the initial HTML is rendered. Hydration primarily involves attaching event listeners to DOM elements in traditional client-side React. In comparison, Server Components play a role in initializing the client component state and allowing them to run effects, such as fetching additional data or interacting with the DOM. Server components rely on the hydration process more because there's less information available at the time of initial render.

Advice For Managing State

We're getting into opinionated territory here. When working on server-driven components, utilizing the URL as a source of truth for the state makes for a nice developer experience when working with Server components in practice.

export const fetchCache = 'force-no-store'

const MyServerPage = ({ params }) => {
  const searchTerm = params?.search

  const response = await fetch('https://api.example.com/data?' + searchTerm)
  const data = await response.json()

  return (
    <div>
      <MyClientComponent data={data} />
    </div>
  )
}

export default MyServerPage

Hopefully, this will help paint a picture of when you may or may not want to use server components. If your entire app is denoted with the "use client" directive, that's okay; it's entirely possible that your application is totally client-side driven. As for client components themselves, they'll be around for as long as React is. Consider that nearly every React application up to this point is not in a position to adopt Server components, especially when JavaScript isn't already running on the server.

Just Enough Server React to Keep It Moving