Before we talk about how the react server components work, let’s make one thing clear; it is not the same as server-side rendering (SSR). Though they both work behind the scenes—on the server, they offer unique functionalities.
Table of Contents
The best way is to envisage the two as distinct, orthogonal features of React 18. As it goes, server-side rendering is not a must to use react server components, and neither is vice versa true. Both can function effectively independently.
So, without further ado, it is time to delve into React server components and explore how they have made building applications on React fast and hassle-free.
React Server Components, launched to break the discord between the server and the client components, enable the two classes to collaborate in rendering React applications faster and with better efficiency.
A React element tree entails a series of different React components that render additional ones. Among these, most get rendered on the browser at the client end. However, this creates an unnecessary lag. To curtail this delay, RSC takes the load from the client side and divides it between the two. In other words, it enables some to get rendered by the browser and leave some for the server.
A fix that drastically boosts page load performance and reduces the bundle size. By their looks, RSC resembles traditional React components, and it is hard to differentiate between them. They both function props and use a render method. However, there is a difference. As it goes, RSC has a few additional perks saved up its sleeves. So, let us cover some advantages of React server components and explain why they deserve the hype.
React server components have a free pass to access data sources, and they utilize the strong suits of both client-side and server-side rendering to make app development supreme.
Firstly, rendering behind the scenes rather than on the browser enables the server to access data sources uninterrupted. So, you don’t have to wait unnecessarily every time you fetch data from GraphQL, the file system, endpoints, or databases. Here, direct access implies servers don’t have to stop at API endpoints to fetch data and can enter any data source directly. Moreover, it enables the user to create internal APIs stringed with multiple data sources to boost load time further.
Secondly, the next major plus lies in how they utilize ‘heavy’ code modules. Unlike the browser, which must download codes from JavaScript bundles, the server is pre-stacked with all needed dependencies. Thus, React server components don’t waste precious load time and resources to go back and forth.
In short, react server components enable the server and the browser to function with near max efficiency by distributing the workload. The former fetches data and renders content, while the latter streamlines interactivity. Result? Faster page loads, small bundle size, and enhanced user experience.
To understand how React server components work, we must first recap a little app development ABC. To clear the confusion and make the two easily decipherable, the React Team defined exclusive extensions for the two components. Every file ending with .server.jsx is a server component, and those with .client.jsx are client components.
Moreover, if a file has neither, it is more likely a component functional as both. This small segregation goes a long way in helping React 18 develop apps efficiently. Besides making it easy for developers to differentiate between the two, the distinction also helps bundlers work smartly.
Bundlers lie at the core of React server components. So, here’s what you must understand. A server component loads on the server while the other runs on the browser. Thus, they have defined domains and can’t operate on opposite territories. This restriction comes into play every time you build an app on React using React Server Components.
Simply put, the client component lacks the privilege to import a server component, as the latter can’t run on the client’s browser. Factoring in the dependency, the client component like this becomes not okay.
// ClientComponent.client.jsx // NOT OK: import ServerComponent from './ServerComponent.server' export default function ClientComponent() { return ( <div> <ServerComponent /> </div> ) }
However, this restriction doesn’t make it impossible to strike a concord between the two. There is a way forward. Behold composition. As it goes, it is legal and valid for the client component to take ReactNode S props, and here lies the seed for collaboration between the two. These props get rendered on the server. Thus, breaking the discord for good.
// ClientComponent.client.jsx export default function ClientComponent({ neighbors }) { return ( <div> <h1>Greeting from client home</h1> {neighbors} </div> ) } // ServerComponent.server.jsx export default function ServerComponent() { return <span>Greeting from server home</span> } // OuterServerComponent.server.jsx // OuterServerComponent can instantiate both client and server // components, and we are passing in a <ServerComponent/> as // the neighbors prop to the ClientComponent. import ClientComponent from './ClientComponent.client' import ServerComponent from './ServerComponent.server' export default function OuterServerComponent() { return ( <ClientComponent> <ServerComponent /> </ClientComponent> ) }
There is no magic spell behind the faster page loads and smaller bundle sizes you get by building applications using React server components. At the core, it is all about the effective division of workload. RSC enables the server to do what it does best, presenting codes on a platter for the browser to execute. As a result, the browser works superfast as it gets components pre-cooked.
In simple words, the server renders its component just how it usually does. However, React server components also initiate the client components on the server by putting placeholders with the info to execute. That, in turn, significantly curtails the load time and takes some steam off client-side processing.
So, when the client components reach their territory, they are pre-cooked, and the browser only has to take the output, do the required, and hit execute.
Undoubtedly, react server components have made building applications much faster with React. The ability to render client components on the server end is no less than a masterstroke that streamlines the entire process from A to Z. Still, RSC is no holy grail, and there are many limitations.
Nevertheless, their existence hints at a bright future for react developers who dream about building applications using React seamlessly and for users who envision a supreme user experience and page performance.
Also Read: How Xperti Can Help You Find React Jobs In The USA
Content Marketer | SEO writer | Tech enthusiast with a passion for writing about the latest trends and innovations in technology, software solutions, or recruiting the best and brightest talent in the tech industry.
Create a free profile and find your next great opportunity.
Sign up and find a perfect match for your team.
Xperti vets skilled professionals with its unique talent-matching process.
Connect and engage with technology enthusiasts.
© Xperti.io All Rights Reserved
Privacy
Terms of use