Elevating user experiences with React Server Components

Opcito Technologies
3 min readNov 27, 2023

What are React Server Components?

React Server Components (RSCs) flawlessly mix the power of server-side rendering with the interactive charm of client-side JavaScript. They take care of complicated tasks in the background, allowing developers to focus on creating exceptional user experiences. What’s truly remarkable is that RSCs, despite their advanced functionality, are essentially the same React Components you’ve been using all along. Imagine them as dependable helpers in the world of web development. They handle the tough work, so developers can focus on creating amazing digital projects.

Let’s delve deeper into the world of React Server Components, exploring the specific issues they address, the reasons for their emergence, and the exciting features they offer.

Why React Server Components ?

To understand why RSCs are used, let’s understand at the challenges that arise in a typical React code and the reasons driving the necessity for React Server Components.

Let’s look at this example:

const App = () => {
return (
<ProductWrapper>
<ProductList />
<Testimonials />
</ProductWrapper>
)
}

The above example shows two components — <ProductList/> and <Testimonials/> that are passed to the <ProductWrapper/> component as child props.
Now, let’s look at the body of each component.

<ProductWrapper/>

const ProductWrapper = ({ children }) => {
const [wrapperData, setWrapperData] = useState();
  useEffect(() => {
// API call to get data for Wrapper component to function and
set it to local state
//For testing purpose
setTimeout(() => {
setWrapperData("ProductWrapper");
}, 1000);
}, []);
// Only after API response is received, we start rendering
// ProductList and Testimonials (children props)
return (
<>
<h1>{wrapperData}</h1>
<>{wrapperData && children}</>
</>
);
};

<ProductList/>

const ProductList = () => {
const [listData, setListData] = useState();
  useEffect(() => {
//API call to get data for ProductList component to function
and set it to local state
//For testing purpose
setTimeout(() => {
setListData("ProductList");
}, 3000);
}, []);
return (
<>
<h1>{listData.name}</h1>
</>
)
}

<Testimonials/>

const Testimonials = () => {
const [testimonialsData, setTestimonialsData] = useState();
  useEffect(() => {
//API call to get data for ProductList component to function
and set it to local state
//For testing purpose
setTimeout(() => {
setTestimonialsData("Testimonials");
}, 2000);
}, []);
return (
<>
<h1>{testimonialsData.name}</h1>
</>
)
}

As evident, every component is tasked with fetching its individual data. Let’s consider that each component requires a specific duration to initiate API calls and retrieve data from the server.

  • <ProductWrapper/> takes 1 sec to respond
  • <ProductList/> takes 2 sec to respond
  • <Testimonials/> takes 3 sec to respond

The problems that occurred:

1. User experience problem -

<ProductWrapper/> is rendered after one second. <ProductList/> is rendered after two seconds. And after three seconds, <Testimonials/> appears. But <Testimonials/> enters the view by pushing <ProductList/> down. This is not a great user experience.

<ProductList/> and <Testimonials/> both components must wait until the <ProductWrapper/> fetches the data and gets rendered on screen, which results in a waterfall. This means, until and unless a parent component doesn’t get its response, the child component must wait to get rendered on the screen.

2. Maintanability -

const App = () => {
const data = fetchAllData();
return (
<ProductWrapper data={data.ProductWrapperData}>
<ProductList data={data.ProductListData} />
<Testimonials data={data.testimonialsData} />
</ProductWrapper>
)
}

As of now, the App component has undergone modifications. It now initiates a request that fetches all the necessary data in a single operation. Subsequently, this fetched data is then distributed to the respective components by passing it along as props.

Imagine a scenario where, in future, the developer decides to eliminate the <Testimonials/> component from the application. If, however, they unintentionally overlook removing a portion of the <Testimonials/> API implementation from the backend, an interesting situation arises. Even though the <Testimonials/> component no longer …read more

--

--

Opcito Technologies

Product engineering experts specializing in DevOps, Containers, Cloud, Automation, Blockchain, Test Engineering, & Open Source Tech