Reaction's 1st Edition: Server Components

Your Premier Source for React Insights and Front-End Delights

Aug 21, 2023

We're thrilled to introduce the inaugural edition of our React newsletter, "Reaction." We're confident that you'll find this newsletter to be a valuable resource, brimming with informative and engaging content. In this issue, we will cover the latest developments in React, as well as popular topics within the front-end development community. Thank you for embarking on this exciting journey with us!

Server Components

Since this is the inaugural edition of the newsletter, we'd like to discuss a topic that has been widely debated in the React community - server components.

What Are Server Components?

As per React's official documentation, server components are components that can be executed during the application's build or on the server. This feature is particularly advantageous since one of the challenges in Single Page Applications (SPAs) is the size of the JavaScript bundle, which can slow down the initial page load on medium to large React applications, consequently affecting the app’s performance. Server components bring several benefits, such as reducing the size of the JavaScript bundle sent to the browser.

Funny meme showing the bundle size sent to the client

Furthermore, server components enable you to perform tasks that you wouldn't normally include in client-side code, such as directly fetching data from a database. You can then utilize the fetched data and incorporate it directly into the JSX of the component. Yes! Code that you would typically encounter in a Node.js or Express project can be implemented in server components without any exceptions.

Drawbacks

You might be wondering if you should use server components everywhere in your application. Unfortunately, the answer is no. This is because, since the component is rendered on the server, you cannot employ anything related to the client side. This includes:

Event handlers like click, mouseon, keydown, and other browser events.
React hooks such as useState, useEffect, useRef.
Browser Web APIs, like local storage.

Components that rely on the aforementioned elements are referred to as client components.

When to Use Client and Server Components

The rule of thumb that I personally follow when deciding between client and server components is as follows: I use server components when I need to render "dumb components" or perform data fetching that doesn't require frequent updates. On the other hand, I opt for client components when I need to introduce user interactivity, such as event handlers or state management. Additionally, it is recommended to position the client components as leaves in the React component tree, as illustrated in the following diagram:

Example depicting how the tree should appear with server and client components

Using Server Components

Frameworks like Next.js are embracing the use of server components. By default, all components created within a Next.js project utilizing the app router are considered server components. To implement client components, you need to explicitly indicate to Next.js that you are utilizing a client component by using the string "use client." With this directive, the client component will undergo the Hydration process, similar to the page router in Next.js.

Server Components vs. Server-Side Rendering (SSR)

It is crucial to note that server components and Server-Side Rendering (SSR) are not synonymous. Server components are React components constructed on the server, remain on the server, and have access to server infrastructure. In contrast, SSR employs Hydration to transform the HTML sent from the server to the client into an interactive React component.

Other Implementations of Server Components

At present, Next.js is the first framework to fully integrate the React architecture for Server Components, Suspense, and Transitions.

In contrast, Remix does not implement server components, asserting that Remix's approach to rendering components is already faster than the server components implementation. As they put it, "RSC alone is insufficient to render as you fetch. It needs a framework above it to kick off a parallel load of resources before rendering." In terms of developer experience, Remix route modules are already "server components." Utilizing server components is merely an implementation detail of Remix itself. You can learn more about Remix's take on server components in the following link, and if you're interested, delve deeper into Remix, which stands as Next.js' primary competitor and the creator of the renowned library React Router.

As for Vite, it is not a framework but rather a category of frontend build tools that significantly enhance the frontend development process. Presently, discussions are ongoing with Shopify developers regarding the implementation of server components within Vite's tooling. They are creating Hydrogen, a novel React framework powered by Vite, accompanied by an array of practical commerce components for use in other frameworks. This new framework incorporates a proprietary version of React Server Components, developed in-house, though they are collaborating with the React core team to create an official version compatible with Vite. Additional information about this discourse can be found in the provided link.

Example

If you wish to observe server components in action, explore our implementation example using Next.js.

Reaction