A few weeks ago the React team has revealed an exciting feature that’s currently still under development: React Server Components.

This “feature” will not only introduce a new type of components for the server but rather a completely new “taxonomy” of React components.

This new taxonomy of components consists of three types:

Server Components are components that can only be rendered on the server. They have direct access to server-side data sources like a database or a filesystem on the server. They “fetch” locally, making the data fetching process faster and more efficient. Server Components are stateless, but can import Client Components, which are statefull and can handle user interactions.

Client Components are components that can only be rendered on the client. It’s the same component that you’ve written using React all this time. Client Components can’t use Server Components. They usually get imported by Server Components and used to display the interactive part of your application. They have no access to server-side data sources, they are statefull and can access the browser APIs.

Shared Components are components that can be rendered on the server or the client, depending on the type of component that uses them. Shared Components were meant to render parts of UI that don’t need to use state or load additional data. For example, a markdown renderer component that needs to transform markdown to HTML can grab the markdown from props and render without any additional changes.

Should all types be included in future React design systems?

Future Design Systems

The term “design system” has many interpretations. In this post, it will be used to signify the infrastructure used by a team or organization, for other web projects authored by them. This includes logic components as well as UI.

A design system must consist of reusable and context-agnostic parts. That seems to exclude Server Components since they are very-much coupled to the server. We can try to fix that by:

1. Using APIs to communicate with the server. That excludes direct data queries and reads from the server’s file system (this is, also more advisable in terms of security).
2. Building abstract Server components — i.e, using props for anything that is context-specific.

But, to be honest, the above solution is quite odd, considering the abstraction of Server Components empties them of any substance. There’s not much universal logic going on there.

Design Systems and Bit

When thinking of future design systems, Bit (Github) must be part of the equation. That’s not only because it is a trending tool but also because the philosophy that drives Bit is a philosophy all of us subscribe to:

Everything should be built using independent components.

Monolithic projects are slow to grow and incredibly hard to maintain. Modularity is the way to go 👍

That is true for web apps but that’s also true for design systems.

A design system built with Bit, is not a single library but a collection of independent components. Each component is authored, maintained, and consumed independently (that does not mean each component needs be authored in a separate repo). That almost inevitably drives the creation of multiple component collections, with different levels of abstraction and different purposes.

For example, components from Bit’s design system, “Base-UI”, are used by components from another, more concrete collection, “Evangelist” (used for their marketing products).

A future React design system built with Bit, will probably consist of :

• React Hooks
• Client [UI] Components
• Shared [UI] Components

Server Components’ place is in more abstract component collections, as they are concrete compositions that consist of their own unique logic and Client/Shared components, from the ‘design system’ component collection.

For example:

import {fetch} from 'react-fetch';
import {ImageCollection} from '@my-org.design-system/image-collection'function Gallery(){
  const images = fetch(`http://localhost:4000/images`).json()return <ImageCollection images={images} />;
}

Learn More