Forem: Jan Koriťák

Server Components vs. SSR in Next.js

Jan Koriťák — Wed, 26 Apr 2023 13:02:00 +0000

Foreword

I recently published an article, in which I discuss the core ideas behind React@18's Server Components. I'd say the article is one of the chunkier ones. It discusses the limitations of React's Client Components and how the Server Components help us mitigate these limitations.

Overall, Server Components are an exciting shift to the React (and Next.js) ecosystem. A next step, that'll enable us - the engineers - to benefit from a new concept with only a slight pivot to the APIs we're used to. Although, the other important question is how severe a mindset shift will the concept require?

Server Components are one more weapon in the already stacked arsenal of today's front-end engineers. Next.js already exposes SSR (Server-side rendering), SSG (Static-site generation), and ISR (Incremental static regeneration). Let's discuss, how RSC (React Server Components) fit into this arsenal and how they work together with the rest of the technologies.

Let's jump right into it, shall we?

SSR vs. RSC

The names and the abbreviations look similar. However, the idea behind both differs significantly. Moreover, you can even leverage both concepts in parallel!

Let's compare the two concepts for these aspects:

When to use them?
What is the output of each?
When is the output built?
What's the granularity?
How to use them in Next.js?

When to use them?

Should we use server-side rendering or a set of server components? Well, what about using both?

SSR

Let's start with SSR. A side note: Next.js uses the term "Dynamic pre-rendering" in place of SSR.

To describe SSR in layman's terms:

The purpose of SSR is to give the user something to look at before JS is executed.

SSR splits the rendering process into two parts:

(Pre)rendering HTML. (server-side)
Hydrating the HTML with JS to achieve interactivity. (client-side)

The HTML is dynamically pre-rendered on the server and then sent to the client along with JS bundle(s) and other assets.

This way, we can present the user with at least a non-interactive website (that usually looks pretty close to the final product) for that couple (hundred) milliseconds, that it takes the browser to load, parse and execute JS.

The motivation behind SSR should be obvious. It's always better to show the user something "tangible" rather than a blank screen. Or do you prefer this?

There are also other classes of benefits, such as better SEO. Not all of today's search engines execute JavaScript when generating page scores, right?

RSC

On the other hand, RSC (React Server Components) is a concept that allows us to decide per component, what to render on the server, and what to render on a client. There is no direct relationship between SSR and RSC. Taking words from the RFC, these two are not supposed to be antagonists, but rather complementary. Meaning, you can even use both simultaneously!

As for the usage, the rule of thumb is to use Server Components by default, over Client Components and use Clients Components only for:

Encapsulating interactive behavior
Interacting with browser APIs

If you're interested in why is it better to render your components on the server by default, you can read my other article or take a look at Next.js docs.

What is the output?

Server-side rending is an established pattern in the front-end world. The Server Components are still quite new and as for implementation quite interesting. Let's look into why!

SSR

This is quite intuitive. The output of SSR is HTML, which is generated on the server side. The markup does not have to be static, it can depend on the dynamic data available at the time of the request!

This allows us to transfer leaner chunks of data to the client and build more responsive pages on slower devices, resp. connections.

RSC

Here comes something new!

The intuitive train of thought here could be that since a React Server Component is just a component, that is rendered on the server, the output could be markup (the same as for server-side rendering), but just a smaller chunk, right? This is a perfectly reasonable train of thought and could as well work, however, this is not how server components work.

The reality is, that instead of a markup-type notation, the React team decided to go with a custom implementation for the RSC serialization format. The result is a custom JSON-like notation that is supposedly simpler to work with (internally) and suited better for transferring components over the network barrier.

Here's an example of a serialized server component.

M1:{"id":"./src/SearchField.client.js","chunks":["client5"],"name":""}
M2:{"id":"./src/EditButton.client.js","chunks":["client1"],"name":""}
S3:"react.suspense"
J0:["$","div",null,{"className":"main","children":[["$","section",null,{"className":"col sidebar","children":[["$","section",null,{"className":"sidebar-header","children":[["$","img",null,{"className":"logo","src":"logo.svg","width":"22px","height":"20px","alt":"","role":"presentation"}],["$","strong",null,{"children":"React Notes"}]]}],["$","section",null,{"className":"sidebar-menu","role":"menubar","children":[["$","@1",null,{}],["$","@2",null,{"noteId":null,"children":"New"}]]}],["$","nav",null,{"children":["$","$3",null,{"fallback":["$","div",null,{"children":["$","ul",null,{"className":"notes-list skeleton-container","children":[["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}]]}]}],"children":"@4"}]}]]}],["$","section","null",{"className":"col note-viewer","children":["$","$3",null,{"fallback":["$","div",null,{"className":"note skeleton-container","role":"progressbar","aria-busy":"true","children":[["$","div",null,{"className":"note-header","children":[["$","div",null,{"className":"note-title skeleton","style":{"height":"3rem","width":"65%","marginInline":"12px 1em"}}],["$","div",null,{"className":"skeleton skeleton--button","style":{"width":"8em","height":"2.5em"}}]]}],["$","div",null,{"className":"note-preview","children":[["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}]]}]]}],"children":["$","div",null,{"className":"note--empty-state","children":["$","span",null,{"className":"note-text--empty-state","children":"Click a note on the left to view something! 🥺"}]}]}]}]]}]
M5:{"id":"./src/SidebarNote.client.js","chunks":["client6"],"name":""}
J4:["$","ul",null,{"className":"notes-list","children":[["$","li","1",{"children":["$","@5",null,{"id":1,"title":"Meeting Notes","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"This is an example note. It contains Markdown!"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Meeting Notes"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","2",{"children":["$","@5",null,{"id":2,"title":"A note with a very long title because sometimes you need more words","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"You can write all kinds of amazing notes in this app! These note live on the server in the notes..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"A note with a very long title because sometimes you need more words"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","3",{"children":["$","@5",null,{"id":3,"title":"I wrote this note today","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It was an excellent note."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"I wrote this note today"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","4",{"children":["$","@5",null,{"id":4,"title":"Make a thing","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It's very easy to make some words bold and other words italic with Markdown. You can even link to React's..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Make a thing"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","6",{"children":["$","@5",null,{"id":6,"title":"Test Noteeeeeeeasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"Test note's text"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Test Noteeeeeeeasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}],["$","li","7",{"children":["$","@5",null,{"id":7,"title":"asdasdasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"asdasdasd"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"asdasdasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}]]}]

To some extent, the format is quite readable, we can see that our component consists of:

Two atoms - a div and an ul. These are Server Components, pre-rendered on the server!
A suspense boundary. Not so interesting in this context.
Two pointers to a Client Component (SearchField and EditButton). These will be rendered on the client.

Here's how could update the diagram from above to reflect the server component architecture. Notice that Server Components can be streamed to the client in parts.

When is the output built?

We discussed what the output looks like. We now know that SSR returns markup, but RSC interestingly enough returns a custom JSON-like notation! Both are obviously built on the server, but each one of them is built in a different part of the flow.

SSR

If you paid attention, we already touched on this topic in the previous paragraphs. The SSR-produced markup is produced at the requested time. This is the reason, why SSR is also called "dynamic pre-rendering", as opposed to "static pre-rendering" (aka. SSG), which produces the markup statically, at build-time.

The flow goes:

The client requests a page from the server.
The server pre-renders HTML and bundles JS.
The assets are passed to the client.
The static markup is rendered.
The static markup is hydrated with JS.

RSC

The server components are more asynchronous and streamable. By design, they are also more granular (we'll touch on this more in the upcoming paragraph), so when there is an UI interaction, that requires a component on the server side, the component is requested by the client, build dynamically on the server and streamed back to the client as an atomic chunk.

If we combine the flow with server-side rendering, we end up with:

The client requests the output from the server.
The server pre-renders HTML and bundles JS.
The assets are passed to the client.
The static markup is rendered.
The static markup is hydrated with JS (state and event handlers attached to the DOM).
✨ An UI interaction happens. ✨
Client requests the relevant RSCs to from the server.
RSCs rendered and serialized on the server and passed to the client.
RSCs are hydrated into the current web page.

Note: The initial chunk can also contain server components. I chose to demonstrate this on an example, where the components are rendered as a result of an user interaction with the page.

What's the granularity?

How granular are the SSR and RSC outputs? This is a straightforward one.

SSR

We can say that the granularity of SSR is 1. By this, we mean that for 1 page, there is only 1 request/response pair that returns the initial server-rendered markup.

After the initial portion of markup is rendered, the SSR served its purpose and is no longer needed.

RSC

Oppositely to SSR, the granularity of RSC >= N, where N is the number of server components used on the page. I'm including the >= operator, as one component may be rendered multiple times. Hopefully, it's cached.

The RSCs allow us to render little pieces of the page on the server and stream them to the client in small chunks, which brings many benefits. The more chunks we decide to defer to the server, the more granularity we introduce. The point is, there is no upper limit to this.

How to use them in Next.js?

Let's talk practice. How do you even trigger SSR or render a Server Component in Next.js? At the time of writing this article, no other frameworks support Server Components out of the box. Of course, you can still configure your server to handle them!

SSR

Next.js is quite an advanced framework, that pre-renders every page by default. Moreover, it lets you choose, whether you want to pre-render statically (during build time) or dynamically (during request time).

Use getStaticProps and getStaticPaths for SSG (default)
Use getServerSideProps for SSR

RSC

As mentioned before, Next.js takes a stance of treating every component as a Server Component by default. If you want to use a Client Component, you'll need to annotate the file with use client; directive at the top of the component file.

Also, don't forget that the concept is only available in Next.js@13 app directory. You cannot leverage it inside the good old pages directory.

Conclusion

Opposed to my previous article which attempts to discuss the benefits of server components in-depth, the idea of this article was to provide answers to quite basic questions that may pop up to a developer who is new to the concept.

Hopefully, I hit the nail on the head at least partially and the article did help you grasp the concept a bit better.

For more articles like this visit Webscope's Blog! We publish two practical technical articles per month.

If you'd like to catch up with me, I'm active daily on Twitter.

Hunting down regression using "git bisect"

Jan Koriťák — Wed, 29 Mar 2023 13:18:27 +0000

Originally published in Webscope's blog: Hunting down regression using "git bisect"

Intro

Regression bugs are the worst! 😠 Especially, when you've just introduced a huge change and you have no clear idea where the regression bug stems from.

I'll show you a quick and reliable path on how to uncover regression bugs with a standard Git command, that not many people utilize, which is a pity!

As this article is discussing a very specific scenario in developers' workflow, let me open with a real-world model scenario, to get you into the context.

You may not even need this article! If you're only here to read about git bisect's API either jump to the bottom or navigate to the Git docs. The point of this article is to discuss a real-life use case rather than duplicate the Git docs.

A real-world scenario

Storytime! 📚

Imagine you're working on a new, fancy feature, that you and the product team are very excited about. Once deployed, the feature is gonna bring a lot of value to your customers, moving you another tiny bit ahead of the competition. And you've been part of that! Exciting! 👏

You've spent days, maybe even weeks working on and perfecting the feature. The day finally comes. You receive the last required approval on your polished pull request. Proudly, you hit the "Merge PR" button and calmly watch the CI/CD pipeline take care of the deployment while sipping your cup of victorious coffee. ☕ You pat yourself on your back and feeling accomplished, you head home.

... fast-forward to the next morning. 🔅

You open your laptop to see a bunch of worrying messages from the product folks. Apparently, while shipping the awesome new feature, a bug 🐛 snuck through all the tests and even the code review! Now, your customers are complaining that something, that used to work before is now not working. You gulp and check out the feature branch, you hoped to never see again.

The root cause is not trivial and this is the commit history of the branch:

2bd81f7 chore: Initial commit
fd1c7ae feat: storing search state in user settings
03d78e refactor: basic tag autosuggest implementation
a2c6f9b feat: improve tag autosuggest algorithm
c1b2e7d chore: refactor search filter implementation
9e6c1a8 fix: correct fuzzy search implementation for tags
6c7d2b2 feat: add search suggestions to input field
e1f9a4d refactor: search input component reorganization
8a3b0c9 feat: add support for searching by date
7dfe573 test: add search performance testing
4a7b8f1 feat: integrate search input with external API
3a8bcb4 chore: add keyboard shortcuts for search input
b50b832 feat: allow searching within search results
d0e2b8f feat: add support for searching by category
5ab5e15 fix: improve search input accessibility
e7ba51c feat: add option to save search queries
4f1df68 test: add search input validation testing
1a2e82c feat: add ability to search within specific fields
0c38d2a feat: implement search input highlighting
e0ef1c6 feat: add support for searching within attachments
6d7e25d refactor: improve autocomplete for search input
9d7fae9 feat: add support for searching by location
6c7f6b3 test: implement search input throttling testing
3f49862 feat: add search input to mobile interface
1cbb0c2 refactor: implement search input suggestions from user history
7b642f1 chore: improve search input placeholder text
3e9a8f8 feat: add support for searching within shared documents
1d4e4d7 refactor: implement autocomplete for search input filters
f52973a feat: add support for searching within comments
7b64df1 fix: improve search input styling and layout

(Don't over-analyze the commit history, it's ChatGPT-generated).

If only you knew, where to start...

Taking a naive approach

If you ask me, that is quite an intimidating number of commits. If the commits are not single-purpose or close to atomic, it's very likely that the diff is not gonna be the smallest as well.

Since we have no idea, where the sneaky bug is stemming from, it's important to realize, we're partially relying on a chance, to discover it. Therefore, debugging by browsing the branch and asserting a bunch of pseudo-randomly placed console.log or debug statements while clicking through the app would be very ineffective here.

After all, you're an engineer and there must be a systematic approach, right?

Tilting the odds in our favor

It's a general rule, that in case you're relying on chance, you better tilt the odds in your favor. How do we do that? We reduce the size of the faulty diff to an absolute minimum.

What's the smallest primitive we can work down to in a Git-versioned repository? You guessed it, It's a commit. In other words. Instead of this.

We want to be digging through something like this.

That sounds like less of a headscratcher, right? 🤔

Leveraging "git bisect"

What it is

git bisect is obviously a Git command and does exactly what we defined in the previous section. It helps us reduce the code to dig through by systematically identifying the first bad commit ("bad" is a terminus technicus here) in Git history.

The process happens in a controlled, iterative fashion (similar to a wizard 🧙), using simple interval-halving, aka. bisection.

How does the command work

When you trigger git bisect, the runner requests two inputs.

❌ A commit (hash) that you know is bad - meaning "is broken".
✅ A commit (hash) that you know good - meaning "works fine".

Once you supply these two interval borders. The runner takes over. Iteratively, it starts checking out commits and asking you, whether things are broken or just fine on this particular commit.

Your only job is to re-run your test scenario, e.g.

Refresh a broken application UI and test the functionality
Re-run the failing test case and check whether it passes
Execute a script and see if it returns 0 this time
... depends on your environment

With each step, it's your job to tell the bisect runner, if the commit is good or bad.

That's it! Since bisection is just another name for binary search, you'll locate the broken commit in very brief log2(number_of_commits) steps. 😎

Looking through a history of 8 commits? You'll know the answer in 3 steps.
64 commits? 6 steps!
Even if you're digging through as many as 1024 commits, you'll know in 10 steps.

You've probably seen a log2(n) chart, right?

A practical example - Visual

Let's take the series of commits from above. Here's a little animation of how git bisect locates the first bad commit.

Let's take 6d7e25d as our broken commit, which we want to "identify". Below, you can watch a little animation of how we bisect from 2bd81f7 (good) and 7b64df1 (bad) all the way to the culprit.

There should be an animation under this line. If it's not, give it time to load. Or click the link below. ☕

📽️ If the embedded animation is too small, feel free to click through this link for a full-screen high-res version! Hope this animation says a thousand words.

A practical example - CLI

In case you're a more hands-on type of person, let's also analyze the whole sequence of commands that lead us to the culprit (0c38d2a) for completeness. If you got the idea from the animation, feel free to skip this. It's gonna be very linear.

Let's go over the command sequence. We start off by asserting the borders of the interval by passing a broken commit and a working commit. In this case HEAD is broken, but 2bd81f7 works just fine.

👨‍💻 git bisect start HEAD 2bd81f7

Git acknowledges the internal borders and checks out a new commit - 5ab5e15. Then informs us that the culprit will be identified in roughly 4 steps. Great!

🤖 Bisecting: 14 revisions left to test after this (roughly 4 steps) [5ab5e15] fix: improve search input accessibility

We re-run the target (application, test, script, ...) and access the commit as good.

👨‍💻 git bisect good

Git acknowledges the good commit and checks out further, to 9d7fae9 .

🤖 Bisecting: 7 revisions left to test after this (roughly 3 steps) [9d7fae9] feat: add support for searching by location

We re-run the target (application, test, script, ...) and access the commit as bad.

👨‍💻 git bisect bad

Git acknowledges the bad commit and checks out further, to 1a2e82c .

🤖 Bisecting: 3 revisions left to test after this (roughly 2 steps) [1a2e82c] feat: add ability to search within specific fields

We re-run the target (application, test, script, ...) and access the commit as good.

👨‍💻 git bisect good

Git acknowledges the bad commit and checks out further, to e0ef1c6 .

🤖 Bisecting: 1 revision left to test after this (roughly 1 step) [e0ef1c6] feat: add support for searching within attachments

We re-run the target (application, test, script, ...) and access the commit as bad.

👨‍💻 git bisect bad

Git acknowledges and checks out the final commit - 0c38d2a.

🤖 Bisecting: 0 revisions left to test after this (roughly 0 steps) [0c38d2a] feat: implement search input highlighting

As we've evaluated all necessary commits, the process ends. Now we know 0c38d2a is the first broken commit that we need to dig through!

I'll now leave you in peace to debug your broken commit! 😊

Final words

The whole idea of using git bisect for debugging, resp. tracing regression is to isolate the smallest possible piece of code, that we reliably identify as faulty. The smaller the diff is, the easier should it is to locate the culprit code.

Now we know, git bisect can take of this in mere log2(number_of_commits) steps. Therefore, even if we're working with a large commit sequence, e.g. of 1024, we can trace the regression bug in mere 10 steps.

Hope you learned something new today and you'll think twice before trying to debug large branches in the future.

Z-index not working? Debug it the modern way.

Jan Koriťák — Thu, 16 Mar 2023 09:07:25 +0000

I usually write technical articles that attempt to dig deep into the selected topic - this is not one of them. This is quite an opposite of your usual tech digest. A simple, but visual article.

⚠️ A sidenote: If you're on a slower connection, mind that the article contains a bunch of GIF examples. Give it time to load.

Originally published in Webscope's blog: Z-index not working? Debug it the modern way.

Intro

If you're scratching your head, lamenting on why is your fancy modal, overlay, dropdown, or tooltip (or any other web element for that matter) covered by another web element, even though you already set its z-index higher than the culprit, you may find this article useful.

What this article is

The article itself explores debugging z-index outside of your standard "Elements" panel. It explores debugging by solely a visual approach, that's implemented in some of the Chromium-based browsers but seems to go mostly unnoticed.

What this article is NOT

It's not a deep dive into what z-index is, what's its relation to "Stacking Context", or how is it formed. Since we're exploring a solely visual way of debugging, being comfortable with these concepts is not a requirement to continue, but I'd strongly recommend reading through basic MDN docs like this one on z-index or this one on "Stacking Context".

A model scenario

Let's take my blog, and break it in a simple, silly way. I hope you can identify the problem.

For those who overlooked the issue - the dropdown elements are for "some reason" rendering under the elements of one of my articles.

Let's get to debugging, shall we?

Debugging in 3D

Now, if you're like me, you'd locate the element, Inspect it in your DEV tools, and start comparing the z-indexes of the dropdown and the article component.

In the simplest scenario, bumping the z-index of the dropdown would do the job. If the markup and styles are more intricate we'd have to start figuring out the formed stacking contexts by going up through all relevant predecessors of our components and fiddling with z-indexes and other CSS properties.

Forget that for now, and let's try something new today. Let's inspect the web page in 3D view and debug the problem visually.

Support

The "3D View" is currently only supported by MS Edge. There are other Chromium browsers, that support similar features called "Layers", however, it seems pretty limited from what I could see, so I recommend attempting this in MS Edge.

Browser	Support	Feature name
MS Edge	✅	3D View
Google Chrome	🟧	Layers (limited)
Arc	🟧	Layers (limited)
Opera GX	🟧	Layers (limited)
Brave	🟧	Layers (limited)

I'm unsure about the rest of the browsers as well as the different implementations outside of Chromium. You'll have to fiddle with that by yourself.

Getting the visual

Let's open up the "3D View".

Open the Dev Tools
Open Command Palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Win)
Find your "Show 3D View" or "Show Layers" command
Execute it

Your Dev Tool will open the desired "3D View" of the web page, so let's explore it.

Debugging, but fun?

Inside the "3D View" panel, you can see three tabs:

Composited Layers
Z-index
DOM

We'll be exploring "Z-index" more, but let's just get those two others out of the way.

Composited Layers tab - Basically renders your (2D) web page in the 3D space. Quite a conservative view, but may be useful for web page elements that naturally stick out of the common view.

DOM tab - What this tab lacks in usefulness for z-index debugging, is it over-delivers in coolness. The tab allows you to basically peel the page layer-by-layer. What is this useful for? I have no idea but look at the colors!

Debugging z-index

Let's get to the debugging part now, we still have a broken web page to fix, so let's visualize the z-index properties of the web page. Remember, we're trying to figure out why the article tile covers our dropdown menu.

Let's observe the web is 3D and try to locate the problem.

From the "3D View", we can observe that on the z-axis, the article tile is positioned above the dropdown. Which exactly maps to the problem we're troubleshooting.

Let's try to reduce the view to give it more clarity.

In the first step, we reduced the amount of all rendered elements by only rendering distinct stacking contexts. Then, by slapping the z-index value labels to our respective contexts, we can see the problem in numbers and figure out the issue - visually.

While Hashnode uses z-index of 50 for the dropdowns, our culprit article tile somehow uses z-index: 51. There we go, silly mystery resolved.

Final words

It's great to see debugging tools are moving way beyond the usual digging in source code. MS Edge's "3D View" is a great example of a hidden gem, that can save you time drilling through markup element by element when debugging z-index-induced bugs.

As a said before, this was everything, but technical. However, I still hope you found this refreshing and useful.

So, why Server Components?

Jan Koriťák — Wed, 04 Jan 2023 10:11:22 +0000

Let's talk components .. but on the server.

But .. why would you want something like that? Are good old (client) components not good enough?

Of course, they are! Client components are a perfect match for rich, interactive UIs that implement immediate feedback loops. However, as it usually goes, each concept implies a certain set of advantages, as well as a certain set of limitations.

Till late 2020, the only option to render a component was doing it client-side, in the browser. Let's discuss some of the major disadvantages of this approach and explore how the concept of React Server Components helps us push the entire ecosystem forwards by addressing these limitations.

Client Components limitations

1. Long TTI (Time to Interactive)

Let's recap how client-side rendering with the help of SSR works.

The client requests a page from the server.
The server builds the JS bundle and hopefully also some basic HTML to give the user a fast, static response.
The server returns the JS assets to the client.
The client renders the HTML.
The client loads, parses, and executes the JS.
The client hydrates the JS into HTML to achieve the desired interactive page.

The red horizontal line in the image indicates where TTI would sit. The heavier the JS bundle, the longer loading, parsing, executing, and hydrating the JS take.

2. Dependencies bloat the JS bundle

The logic is somewhat linear. The heavier the bundle, the longer will it take to transfer it over the network barrier to the browser and the longer will it take to render it. However, an example speakrs a thousand words, so let's bring in some code.

I borrowed this piece of code from the React Server Components demo Notes application.

import {format, isToday} from 'date-fns';
import excerpts from 'excerpts';
import marked from 'marked';

import ClientSidebarNote from './SidebarNote.client';

export default function SidebarNote({note}) {
  const updatedAt = new Date(note.updated_at);
  const lastUpdatedAt = isToday(updatedAt)
    ? format(updatedAt, 'h:mm bb')
    : format(updatedAt, 'M/d/yy');
  const summary = excerpts(marked(note.body), {words: 20});
  return (
    <ClientSidebarNote
      id={note.id}
      title={note.title}
      expandedChildren={
        <p className="sidebar-note-excerpt">{summary || <i>(No content)</i>}</p>
      }>
      <header className="sidebar-note-header">
        <strong>{note.title}</strong>
        <small>{lastUpdatedAt}</small>
      </header>
    </ClientSidebarNote>
  );
}

The code above describes quite a straightforward component. Most notably the component formats and renders a date-time value and formats and renders a piece of markdown that is a summary of a note.

To achieve this, the component uses 3 dependencies date-fns, excerpts, and marked. When we examine the dependencies closer, we can immediately see, they sum to ~80KB gZipped. Keep in mind this is only one client component and consider yourself, how large can the entire application get?

3. Susceptible to request waterfalls

Let's start with a quote:

Rendered JS does not guarantee an useful UI.

If we do all the work we discussed in Long time-to-interactive, to only present the user with something like this. We probably can agree we didn't do the best job in the initial user experience.

Now imagine, the spinner is rendered by a component tree similar to this.

import React from 'react';
import Spinner from 'components/Spinner';
import Something from 'components/Something';

const ChildComponentA = () => <Something />

const ChildComponentB = () => {
  const dataC = useDataC();

  return dataC
    ? <Something />
    : <Spinner />
}

const Root = () => {
  const dataA = useDataA();
  const dataB = useDataB({ skip: !dataA });

  if (!dataA || !dataB) {
    return <Spinner />
  }

  return (
    <>
        <ChildComponentA data={dataB} />
        <Something />
        <ChildComponentB data={dataB} />
    </>
  )
}

From the code above, we can derive the fact, that to present the user with a full user experience, we'll need to fire and wait for three sequential queries. All this, in sequence, after we fetched the JS bundle from the server and rendered the initial UI on the client.

It should be pretty obvious that the diagram is far from optimal. With the current set-up, we're firing three requests to the same server, for each request have to wait for the server to resolve the request by e.g. talking to DB, a close (micro) service, or maybe an FS and then returning the result. Three requests equal three round-trips from client to server and back.

4. The browser has only one thread

The browser still has only one thread reserved for JS runtime. This means, all the operations we've mentioned so far have to run with a single call stack.

5. The browser can't access server APIs

Quite obviously, the browser can access browser APIs like DOM manipulation APIs, fetch API, or Canvas/WebGL, while the server can work with e.g. environment variables, access local file-system, and can directly reach out to databases or services, which the client can only reach out via a controlled proxy.

This is all for the better, as it allows us to securely work only with exposed REST/GraphQL API to talk to the BE resources. However, there are use cases where a little more control would result in a more comfortable development experience. For E.g. developers tend to struggle to realize they only can access environment variables in Next.js in server-side code, as process.env differs on the client. You can definitely work around this by making the variable of the choice public by prepending its name with the PUBLIC_ prefix, but you always need to pay attention not to leak a private variable this way.

It would be great, if we could access process.env directly in a component, without limitations though, right?

Server components to the rescue

We managed to explore the intrinsic limitations of React's client components. These limitations are implied by the concept of rendering the component in the browser environment, or on the client if you will.

Let's now turn the list around and look into each of the limitations, one by one again, and discuss how Server Component help us counter the limitations by unlocking a completely new set of possibilities, by rendering them in the server environment.

1. Long Shorter TTI (Time to Interactive)

One of the amazing benefits of rendering components on the server is that we don't have to transfer as large JS bundles to the client anymore. If our application tree consists of 1000 components and we manage to (pre)render 500 of them server-side, we can be certain, that the JS bundle will be dramatically thinner. The less JS we need to transfer and then load, parse and execute on the client, the quicker will the initial experience be.

The rendered Server Components are not included in the JS bundle, they are rendered on the server and serialized into a special notation designed by the React.js team. This notation not only helps React@18/Next.js@13 transfer the code over the network barrier but also helps client-side React reconcile the component tree update without losing the application state.

To expand the context, let's pull up an example of a batch component update coming from the server to update the UI.

The data are again taken from the React Server Components demo Notes application.

M1:{"id":"./src/SearchField.client.js","chunks":["client5"],"name":""}
M2:{"id":"./src/EditButton.client.js","chunks":["client1"],"name":""}
S3:"react.suspense"
J0:["$","div",null,{"className":"main","children":[["$","section",null,{"className":"col sidebar","children":[["$","section",null,{"className":"sidebar-header","children":[["$","img",null,{"className":"logo","src":"logo.svg","width":"22px","height":"20px","alt":"","role":"presentation"}],["$","strong",null,{"children":"React Notes"}]]}],["$","section",null,{"className":"sidebar-menu","role":"menubar","children":[["$","@1",null,{}],["$","@2",null,{"noteId":null,"children":"New"}]]}],["$","nav",null,{"children":["$","$3",null,{"fallback":["$","div",null,{"children":["$","ul",null,{"className":"notes-list skeleton-container","children":[["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}]]}]}],"children":"@4"}]}]]}],["$","section","null",{"className":"col note-viewer","children":["$","$3",null,{"fallback":["$","div",null,{"className":"note skeleton-container","role":"progressbar","aria-busy":"true","children":[["$","div",null,{"className":"note-header","children":[["$","div",null,{"className":"note-title skeleton","style":{"height":"3rem","width":"65%","marginInline":"12px 1em"}}],["$","div",null,{"className":"skeleton skeleton--button","style":{"width":"8em","height":"2.5em"}}]]}],["$","div",null,{"className":"note-preview","children":[["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}]]}]]}],"children":["$","div",null,{"className":"note--empty-state","children":["$","span",null,{"className":"note-text--empty-state","children":"Click a note on the left to view something! 🥺"}]}]}]}]]}]
M5:{"id":"./src/SidebarNote.client.js","chunks":["client6"],"name":""}
J4:["$","ul",null,{"className":"notes-list","children":[["$","li","1",{"children":["$","@5",null,{"id":1,"title":"Meeting Notes","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"This is an example note. It contains Markdown!"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Meeting Notes"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","2",{"children":["$","@5",null,{"id":2,"title":"A note with a very long title because sometimes you need more words","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"You can write all kinds of amazing notes in this app! These note live on the server in the notes..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"A note with a very long title because sometimes you need more words"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","3",{"children":["$","@5",null,{"id":3,"title":"I wrote this note today","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It was an excellent note."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"I wrote this note today"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","4",{"children":["$","@5",null,{"id":4,"title":"Make a thing","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It's very easy to make some words bold and other words italic with Markdown. You can even link to React's..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Make a thing"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","6",{"children":["$","@5",null,{"id":6,"title":"Test Noteeeeeeeasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"Test note's text"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Test Noteeeeeeeasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}],["$","li","7",{"children":["$","@5",null,{"id":7,"title":"asdasdasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"asdasdasd"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"asdasdasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}]]}]

That's a JSON-y-looking mess! At least it sure feels like that to the human eye. After all, it's a set of instructions for React runtime on how to update the application as a result of e.g. a user's action. These instructions are likely therefore not designed with human readability in mind. However, it's still pretty close to a JSON, so on a second glance, we can see some patterns there, right?

We can identify a bunch of shorter lines, e.g.:

M1:{"id":"./src/SearchField.client.js","chunks":["client5"],"name":""}
M2:{"id":"./src/EditButton.client.js","chunks":["client1"],"name":""}
M5:{"id":"./src/SidebarNote.client.js","chunks":["client6"],"name":""}

The first line is actually instructing React runtime to render a SearchField component, that is located in a file called client5. In other words, it's a pointer to the Client Component, which is located in a JS bundle chunk, called client5. Since it's a Client Component, it's yet to be rendered.

We can also clearly identify a line marking a suspense boundary, which is not that interesting.

S3:"react.suspense"

But there are also two more lines starting with J0 and J4, that look pretty expressive.

J0:["$","div",null,{"className":"main","children":[["$","section",null,{"className":"col sidebar","children":[["$","section",null,{"className":"sidebar-header","children":[["$","img",null,{"className":"logo","src":"logo.svg","width":"22px","height":"20px","alt":"","role":"presentation"}],["$","strong",null,{"children":"React Notes"}]]}],["$","section",null,{"className":"sidebar-menu","role":"menubar","children":[["$","@1",null,{}],["$","@2",null,{"noteId":null,"children":"New"}]]}],["$","nav",null,{"children":["$","$3",null,{"fallback":["$","div",null,{"children":["$","ul",null,{"className":"notes-list skeleton-container","children":[["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}]]}]}],"children":"@4"}]}]]}],["$","section","null",{"className":"col note-viewer","children":["$","$3",null,{"fallback":["$","div",null,{"className":"note skeleton-container","role":"progressbar","aria-busy":"true","children":[["$","div",null,{"className":"note-header","children":[["$","div",null,{"className":"note-title skeleton","style":{"height":"3rem","width":"65%","marginInline":"12px 1em"}}],["$","div",null,{"className":"skeleton skeleton--button","style":{"width":"8em","height":"2.5em"}}]]}],["$","div",null,{"className":"note-preview","children":[["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}]]}]]}],"children":["$","div",null,{"className":"note--empty-state","children":["$","span",null,{"className":"note-text--empty-state","children":"Click a note on the left to view something! 🥺"}]}]}]}]]}]
J4:["$","ul",null,{"className":"notes-list","children":[["$","li","1",{"children":["$","@5",null,{"id":1,"title":"Meeting Notes","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"This is an example note. It contains Markdown!"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Meeting Notes"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","2",{"children":["$","@5",null,{"id":2,"title":"A note with a very long title because sometimes you need more words","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"You can write all kinds of amazing notes in this app! These note live on the server in the notes..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"A note with a very long title because sometimes you need more words"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","3",{"children":["$","@5",null,{"id":3,"title":"I wrote this note today","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It was an excellent note."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"I wrote this note today"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","4",{"children":["$","@5",null,{"id":4,"title":"Make a thing","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It's very easy to make some words bold and other words italic with Markdown. You can even link to React's..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Make a thing"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","6",{"children":["$","@5",null,{"id":6,"title":"Test Noteeeeeeeasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"Test note's text"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Test Noteeeeeeeasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}],["$","li","7",{"children":["$","@5",null,{"id":7,"title":"asdasdasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"asdasdasd"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"asdasdasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}]]}]

The lines J0 and J4 are in fact two atomic components - div and unordered list - that were rendered on the server and completely serialized to be dumped into the view on the client. The browser does not have to perform any work to render these. Of course apart from the reconciliation and the update itself. Very cool, right?

From the client-server communication point of view, the diagram would now look something like this.

The green rectangles mark differences from the pre-React@18/Next.js@13 we mentioned in Long TTI. To sum it up, notable facts are:

Server bundles only the Client Component to the JS bundle
Server renders Server Component into instructions for React runtime, not HTML
The updates are streamed to the client
The client can reconcile the changes while keeping the client's state

The bottom line is - less JS, shorter TTI!

2. Dependencies no longer bloat the bundle

0-bundle size components are another great argument for Server Components. Since the components are compiled on the server. There is no need for us to include the component dependencies inside of the JS bundle.

From the implementation point of view, when server-side React@18 encounters a Server Component in the component tree, it compiles the component into atoms. For E.g. in case your component uses date-fns/format to format a date, it'll happen on the server and the result of the operation will be transferred to the client, without the dependency itself.

Say farewell to bundling heavy dependencies to execute on the client.

To update the image we used above, we can just scratch the ~80 gZipped KBs and replace it with straight 0.

3. Request waterfalls with zero round-trips

A Server Component is always closer to the hardware than a Client Component. Every request that would go from client to server and back now lives fully on the server side. To put this thought into a diagram, let's update the request waterfall we discussed in to reflect that.

The clear difference to the Client Components architecture is that we only need to really do one round-trip. Notice the colorful arrows, that denote the actual requests on the component level that stay server-side. If the waterfall exists, it's way faster.

4. The server has more than one thread

This one is pretty obvious. While browsers still reserve only one thread for JS runtime, servers usually feature more than a single thread for Node.js. More bandwidth for Server Components!

5. The server (obviously) can access the server APIs

When rendering components on the server, we can directly access e.g. process.env variables, therefore we can seamlessly integrate corresponding logic directly into our components. That's quite slick, right?

Moreover, we can directly access local databases, file systems, or (micro)services. I'm not implying accessing a DB directly from a component is the best idea, but you get the point. However, there is a great use case for accessing an FS directly in the component e.g. when implementing a static blog by just mapping the fs into blog pages, which would not be possible on the component level before React@18.

Summary

We explored 5 pre-React@18 pain points that Client Components do suffer from. Server Components allow us to view components in a different light (meaning environment), which turns out to provide implicit solutions for all of the pain points we explored.

Hopefully, the article gave you a better idea of why React@18 pivoted towards Server Components, why Next.js@13 treats a component as a server one by default, unless told not to, and overall, how will the ecosystem look in the near future.