Today I learned

React Server Components

React Server Components are one of the most talked topics in the React community right now.

They are a new way to build React apps that will be released in the future. They are not yet available, but we can already start to learn about them.

They were first introduced as an RFC (Request for Comments) in December 2020. Here is the blog post, where they were introduced as a current research: Introducing Zero-Bundle-Size React Server Components ↗ Opens in new tab

And here is a link to the RFC, which is super interesting to read, to get the idea behind them and how the concept developed since then: RFC: React Server Components ↗ Opens in new tab

Dan Abramov, one of the React core team members, has been putting a lot of effort into educating everybody on Twitter and answering questions about them.

He recently met up with Kent C. Dodds and Joe Savona, whos Tech lead in the React organization in Meta. I totally recommend to watch the whole video: React Server Components with Dan Abramov, Joe Savona, and Kent C. Dodds ↗ Opens in new tab

They tried to answer all of Kents' questions about React Server Components and there was a lot of insights to be learned.

In this post I want to summarize the most important things I know about React Server Components so far.

In the future, we'll be able to differentiate between Server Components and Client Components. Both will have different abilities and limitations. Let's take a look on the things they can do:

Server Components

• can directly access server data
• can use this data to generate html and return it to the browser
• read data on the server, pass it down by props
• each component can fetch the data that it needs
• they can hand of the rendering to the client by importing and rendering a "client" component
• includes the server into the unidirectional data flow
• maybe we don't need to build APIs anymore, when using server components
• they can't use state or effects
• they can't use browser-only APIs like the DOM
• help to reduce the bundle size, by giving us the ability of shifting third-party dependencies to the server

Client Components

• are inside the server components
• can be interactive JSX components
• HTML created at runtime in the browser from JavaScript
• are marked with 'use client' at the top and therefore only included in the bundle if they are used
• can use state, effects, lifecycle methods, custom hooks
• the components we are already used to

To fully understand this new separation, lets take a look at a simple example:

// server
import db from './db'
import UserDetail from './UserDetail'

export const User = () => {
  const user = db.getUser(id)
  return <UserDetail user={user} />
}

// client
'use client'
export const UserDetail = ({ user }) => {
  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  )
}

In this example, the server component User fetches the user data from the db and passes it down to the client component UserDetail. The client component then renders the HTML.

This is a very simple example, but it shows the basic idea of how server and client components work together.

The split between server and client components will enable us again to take full advantage of the server. By shifting several main tasks, like data fetching, to the server, we can reduce the bundle size and improve the performance of our apps.

I'm very curious to see how this will work in practice. I think it will be a big step forward for React and the whole ecosystem. And maybe a totally new way to build web apps in the future.

I hope you enjoyed this post and learned something new. If you have any questions, feel free to reach out to me on Twitter ↗ Opens in new tab or via Email ↗ Opens in new tab.

If you want to support me, you can buy me a coffee. I would be very happy about it!

I wish you a wonderful day! Marco