React Labyrinth: A Helping Hand with React Server Components
Our solution to reduce the Ramp-up time of transitioning to React Server Components
What is React Server Components?
React Server Components (RSC) is a new paradigm being developed by React that allows for traditional components (referred to as Client Components under RSC) that have data fetching and database querying to be done completely on the server, where the latency for these responses are much quicker than on the client. These components that would now be executed solely on the server are aptly named Server Components, and their fully rendered HTML outputs are streamed over to the client after the data fetching or database query is complete. While this new shift in writing React applications is still considered “experimental” for the React library as a whole, certain React frameworks such as Next.js (available in versions 13+), have already begun to implement these new changes for developers to consider using.
Why should I use React Server Components?
While adopting a new way of writing code in a pre-existing codebase may not be the most enticing of ideas, some considerable performance benefits come along with these efforts.
One of the most notable improvements is minimizing your application’s overall client-bundle size. With reductions ranging anywhere from 18–29%, and depending on how your application is configured, even more! This means that the overhead for new features or new libraries that would be beneficial to your team during development, may not need to be at the cost of increasing the memory required of your users to enjoy these new features. The way this is accomplished is by the Server Components performing all necessary data fetching and data querying on the server before streaming the result to the client-side to be displayed on the initial request. At which point, the Server Components are left out of the bundle completely and only the Client Components are sent over.
Another piece to consider is the increased efficiency in Time-to-Interactive (TTI) and First Contentful Paint (FCP) speeds. As previously mentioned, Server Components have a significant advantage in fetching and querying speeds when compared to Client Components, due to Client Components relying on the user’s internet connection speed or location, whereas Server Components have very low latency in these requests. The quick response times, when coupled with React’s <Suspense> feature or the loading file from Next.js (which uses <Suspense> under the hood), lets the user see the parts of the page that were rendered on the server, as well as the few parts that are still being downloaded from the client-bundle until the page is fully hydrated with the JavaScript.
Lastly, Search Engine Optimization (SEO) is another area of improvement that Server Components allow for. This is due to the Server Components already having their HTML outputs being sent to the client on the initial request. The reason this is so helpful is that the search engine bots can only see what your application shows on the DOM on the initial request; to clarify, using Client Components when you have content that would need to be dynamically rendered, the search engine bot is unable to read that content and show it to a user who might be searching for something related to your application due to the dynamic content being loaded solely on the virtual DOM.
Note: For real world examples of results from these changes, check out these articles for the improvements and some of the challenges from migrating to RSC.
How does React Labyrinth help with the transition?
A big challenge in making this leap in your current codebase is knowing where to start. Going through each of your files and checking which components are manipulating the state, or have some listener that would qualify it as a Client Component rather than that of a Server Component, is very tedious.
That is why our team created React Labyrinth: to automate the process of finding these components and acting as a template for the switch to RSC. We wanted to create a tool to help developers transition to RSC by designing a VS Code Extension that is local to their source code for ease of reference and would visualize their React application to notify them where these changes could be made. Our extension takes in the root file of an application and parses through the Abstract Syntax Tree (AST) of each file, and can then determine which components would be a Client Component or a Server Component, to serve as a guide for this migration. These distinctions are made by verifying that if a component has functionality that would modify the state or the view for the user, then it would be a Client Component, and if that were not the case, it would be left as a Server Component.
We hope to be bringing in a metrics feature in the near future that would be able to give you as the developer insight into what these changes could mean for your application’s performance, so you may make a more informed decision when determining if this overhaul would be worth it for you and your team.
Conclusion
We understand that every application is different and may not be best suited for implementing RSC, but for the applications that have begun to kick the tires on what RSC has to offer, we are here to help! React Labyrinth is now available for FREE on the VS Code Extension Store and at the time of writing this article React Labyrinth only runs on MacOS & Linux (Windows coming in a future version release). It is Open-source so all developers are welcome to contribute to making this extension as useful as possible for the community of fellow engineers!
We also have an article that discusses in detail working with the VS Code extension and how the data flows within it! You can read it HERE!
Check out our Github repository here to contribute!
Our team
Ashley Luu — LinkedIn & Github
Christina Raether — LinkedIn & Github
Francisco Lopez — LinkedIn & Github
