Topics In Demand
Notification
New

No notification found.

Elevating user experiences with React Server Components
Elevating user experiences with React Server Components

15

0

Imagine interacting with a website that feels sluggish, unresponsive, ore confusing. Now, picture an experience that's intuitive, responsive, and anticipates your needs. That's the power of user experience (UX) in action. Today, a positive UX is no longer nice to have; it's a necessity. React Server Components (RSC) emerge as a powerful tool to elevate UX by enabling faster loading times, improved interactivity, and a more seamless user journey.

What are React Server Components?

React Server Components flawlessly mix the power of server-side rendering in React 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 use React Server Components ?

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

Let’s look at this example:


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/>



<ProductList/>

<Testimonials/>

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

What problems do traditional React Components create? 

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 -

 

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 exists within the application, the backend can generate responses related to Testimonials. This circumstance gives rise to a significant issue regarding "maintainability". Essentially, devs end up receiving redundant data, which can complicate the overall management and upkeep of the application.

3. Cost

Using libraries is like a treat for developers, but it can make the app heavier and slower. Many parts of an app are like calm waters, and there’s no need for constant splashes from user actions. Imagine a "details" page where you just soak in info about a product or a user – it doesn't need to dance to every user tap. In Server Components, developers can go wild with third-party packages without worrying about their bundle size puffing up.

Basic architecture diagram of Client Components and Server Components

Client Component:
React Server Component

Server Component:

React Server Components

 

How do React Server components solve these problems?

Server components are designed to tackle the problems mentioned above. To quickly sum it up, components on the user's end ask the React server for information, and one must wait for the server's response before showing more parts of the app. This can cause a cascade effect like waterfalls when there's a sequence of these requests happening.

To simplify it, move the data gathering to the server for speed. Data fetching from the server is way faster than fetching from the user’s device. Sounds good, right? But there's a catch. Developers cannot use familiar tools like hooks (useState, useEffect), Web APIs (localstorage), or actions like clicking a button (onClick) as usually done in React. This is because Server Components are built on the server side. They work great when real-time updates or user actions aren't a must-have.

Take a quick look at what a Server Component appears like:


Did you notice a React Component making a call to a database? This is possible because of a Server Component called <Product/>. It's like any other React component, but with some unique powers, as shown in the example above (direct access to a database). But remember, one cannot call the database directly inside the Client Components. (Regular React Code).

Now, let's focus on the <Product/> component. But, what about the <ProductEditor/> component inside the <Product/> component? Here's what the body of the <ProductEditor/> component looks like.


In the above code, 'use client' is used to declare this component as a client component.

Whenever 'use client' is used at the beginning of a file, that component is known as a Client Component. If 'use client' isn't used, then the component in that file is treated as a Server Component.

To summarize -

 

  • Client Components can be imported inside Server Components.
  • Server Components cannot be imported inside Client Components.
  • A Server Component can be passed as a child prop to a Client Component inside the Server Component as shown in above code snippet.
  • It is recommended to user Server Components as the root component where you fetch all the data from server and keep your Client Components as leaves of the tree where it will rendered on the browser.

Where can you start using React Server Components?

If you're interested in exploring Server Components, Next.js 13 offers an excellent platform to get started. The framework makes Server Components easy to use by default, which is a great improvement. Take some time to experiment with Server Components in Next.js 13 and discover their benefits firsthand. Transform your applications with cutting-edge technologies like React Server Components using our Application Modernization services

 


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.