Initial Thoughts on React Server Components

I recently got around to catching up on React Server Components and have shared a few of my initial thoughts. Some may not even need this when it comes out, if you cache your pages properly using a service worker but it’s interesting nonetheless. More information on RSC here  
 

React Server Components (RSC) ‘combine rich interactivity of client-side apps with the improved performance of traditional server rendering’.

Long story short — say you make a search for a specific result in a page with a search bar:  
 

1 ) a network request is made to the BE and then the component is rendered, data is fetched and the component is loaded with the data, all of this happens on the server itself. This loaded component is sent back as an intermediate format (likely to be HTML when the streaming HTML renderer is completed upon release of RSC)  
 

2 ) Frontend renders this intermediate markup as static UI  
 

RSC would be requested and sent when needed and not on page load like traditional SSRs do, meaning the SPA that uses React Server Components will look similar to a regular client side app (with no HTML content initially)  
 

React already offers server side rendering (SSR) in the form of react-dom/server which serves up static HTML markup from react tree components but this library also requires devs to add interactivity with client side JS and take care of navigation, caching and also re-hydrate state (which involves rerendering the page in the server with the new state and sending it back to the FE).  
 

Next.js offers SSR and takes care of all these hassles — it allows devs to statically export components (which involves splitting a component using ‘dynamic import’ rendered on a server) but only if you create a page for that component — this is just 1 reason devs could benefit using RSC over Next.js.  
 

It’s important to note that you still can’t make these RSC interact-able , just like you can’t make SSR pages interact-able without going through extra efforts. Because these RSCs are just chunks of UI updates and we’re not hydrating them, so we can’t have server side components (RSC in this case) inside our client side components because our client side components are mostly interact-able (contain JS that perform actions based on user input). But we can have client side components inside server side components — for example we can have a static page loaded by the server holding several client side components.  
 

So to conclude, benefits of using RSC include:  
 

1 ) Being able to statically export components from the server without the component needing to be a page — other SSRs don’t offer this. Statically exporting components from the server means less initial load on the page which is what I’m most pleased about with this update.  
 

2 ) Since the backend serves up the component as an intermediate format, we can reference backend variables in the frontend components. We can use react-fs to access the file system from frontend components.  
 

3 ) Zero bundle components: if a regular static component imports react-markdown or some other library that is barely used in the application, our frontend bundle size bloats just for the single use of a library. If we do not want to send the whole code of the npm package to the client we can convert that component into a RSC which means installing this package takes place on the server and doesn’t bloat our frontend bundle size.  
 

Note: this offers the same SEO benefits as a regular SPA would with no advantages that a SSR app provides, but modern crawlers like GoogleBot typically load the React components as part of the JS bundle, request data and render the components with the data and inject them into the DOM and only then do they crawl the final DOM so it’s not too bad in terms of SEO when compared to an SSR app.  
 

Happy Friday!

February 5, 2021

ReactJs