Forem: Nadia Makarevich

Tailwind vs Linaria: Performance Investigation

Nadia Makarevich — Fri, 25 Apr 2025 01:51:46 +0000

What's your position on Tailwind? Love or hate? Seems to be no in-between for that one. Even if you've never used it, you probably heard of it by now. It's the second most popular UI framework out there after all, and the source of lots of hype in certain corners of the internet.

One of Tailwind's big selling points that I keep seeing is that it's The Best for performance these days. This got me curious. We have all the modern approaches, the rise of build-time CSS solutions, and even the good old CSS modules, and Tailwind wins over all of them?

So, of course, I had to investigate, compare it with something modern, and see for myself. But make no mistake - this is not just a simple comparison of two CSS solutions. This is a proper detective story, with its ups and downs, hidden clues, plot twists, side quests, and a satisfying ending. And in the process, we'll finally put the theoretical knowledge from the last three articles to some good practical use.

So don't read this article to find out what is better for your next project, Tailwind or not Tailwind. Read it to test your performance intuition, practice performance reasoning, investigate assumptions, ask questions, and get answers. And to have some fun!

Setting up the investigation

We're going to practice our performance investigation skills a lot this time, so you'd need to know what is initial load, how to measure it, how to read a performance flame graph, what the difference is between CSR (client-side rendering) and SSR (server-side rendering), and how to find that difference on the graph. If you skipped the previous articles and feel slightly fuzzy on those topics, you might want to start there first:

We're going to investigate the difference in performance between Tailwind and Linaria. Tailwind, you already know. And Linaria has been getting quite a lot of traction since styled components went into maintenance mode recently. We'll cover why Linaria is a good choice for this comparison a bit further.

Typically, investigations like this would be performed on small synthetic examples. Like rendering a styled button on a page a million times. Personally, I try to avoid those examples. Because, while measurements like this have their value and can provide easy-to-compare numbers, they tell me absolutely nothing about the real world. In the real world, no one renders a million buttons on the same page.

So I want to avoid buttons here and try to measure a real app. Normally, it's almost impossible. You'd need to have a large enough app to be considered at least semi-real-world. Which is already days, if not weeks, of work. And then you need to re-implement this app again, in exactly the same way, only with the different framework/solution you want to measure.

Fortunately, this is not the case today. First of all, I already have quite a large app to play around with. For the previous article, the SSR deep dive, I implemented a fully styled, beautiful app with three pages: Login, Dashboard, and Settings. All with different CSS, different layouts, and lots of components. And it's in Tailwind already. It's not the largest app in the world, but it should be good enough for the purpose.

All I need to do now is to refactor the app from Tailwind to Linaria. Which is, thanks to my good smart friend Claude, is almost trivial these days, if you don't mind some occasional hiccups and botched dark mode. Which I'm totally fine with for the purpose of this exercise. Less than an hour of work, and the entire app is in Linaria instead of Tailwind. What a crazy world we live in!

Now, I just need to start measuring stuff. For the rest of the article, all measurements are:

In “production” mode on a pre-built app.
Performed in the latest Chrome version with 6x CPU slowdown and Slow 4G Network throttling.
A median of 3 measurements, to eliminate the random fluctuations.

You can download the original “baseline” repo with Tailwind and the AI-converted Linaria version now.

Why Linaria vs Tailwind: reasoning and initial assumptions

But before measuring anything, we need to understand what exactly we're trying to measure. Or, more precisely, what exactly we're trying to prove with those measurements, and why.

Why Linaria?

To understand that, we need to remember that underneath every website we see in the browser, regardless of which framework was used to create it, are just three things: HTML, JS, and CSS.

When we first access the website, the browser will download some HTML as the immediate response, extract from that HTML links to the CSS files, wait for them, and only when it has both of them together, it will be ready to render something on the screen. This is called “critical path”, which we covered in detail in the Initial load performance article.

So, the size of the initial HTML and CSS determines initial load performance, i.e., how long the user has to wait to see something meaningful on the screen.

“Normally”, we'll style our HTML with CSS classes. In React, it's the className property, which is converted to class when the page is served to the browser.

// somewhere in React code
<button className="my-button">I'm a button</button>

// converted to HTML at some point
<button class="my-button">I'm a button</button>

// somewhere in a separate CSS file
.my-button {
  display: flex;
  background: red;
  padding: 1rem;
  // all other button's CSS
}

However, for many historical reasons that are out of the scope of this article, writing “raw” CSS is a massive pain. This is where a myriad of tools and frameworks come in, all united by the single goal: to make the dev experience for writing CSS tolerable.

Linaria (and other similar frameworks), for example, among other things, allows you to write your CSS inside your React code:

// somewhere in React code - no separate CSS file!
const myButtonCss = css`
  display: flex;
  background: red;
  padding: 1rem;
  // all other button's CSS
`;

const MyApp = () => {
  return (
    <button className={myButtonCss}>I'm a button</button>
  );
};

Then, during the build step, this CSS is extracted from all the React files, merged together into a regular CSS file, and the className is replaced with a made-up name:

// somewhere in the final CSS file
.blaBla123 {
  display: flex;
  background: red;
  padding: 1rem;
  // all other button's CSS
}

// somewhere in JS/HTML
<button class="blaBla123">I'm a button</button>

If you want to see how it looks in practice, it's a good time to download the “Linaria” app we're going to measure.

Install and build it:

npm install
npm run build

And take a peek into the dist folder. You'll see the index.html file that references an index CSS file from the assets folder. Inside the CSS file, you'll see a bunch of weird classes - all of those are generated during the npm run build step. You can see how it looks in the “real” code in almost every React file. For example, the Login page has lots of them.

This is why I used Linaria: it's just a modern way to write the “traditional” CSS. If you don't like it, you can replace it with any build-time solution, including CSS modules, with essentially the same result.

What's up with Tailwind?

Tailwind, at its core, is the same - it also hooks up to the build system and produces a “raw” CSS file. If you download the “Tailwind baseline” project that we compare to Linaria, and install/build it, you'll see the same result: the index.html file in the dist folder that references an index CSS file from assets.

The developer-facing part, however, is very different. Instead of allowing you to write “regular” CSS in some improved way, like Linaria does, Tailwind completely hides it under a bunch of “utilities” classes. Each class would correspond to one (or more, but usually one) CSS value.

For example, display: flex would correspond to flex class, padding: 1rem to p-4 class, background: red to something like bg-red-500, and so on. As a result, the Linaria-style button from above, with Tailwind, would be written like this with the same result:

// there is no visible CSS here! Just a bunch of standard class names
const MyApp = () => {
  return (
    <button className="flex p-4 bg-red-500">
      I'm a button
    </button>
  );
};

In theory, this increases the re-use of CSS by a lot. If I want to introduce a completely different component that has nothing to do with a button, but happens to have the same display, padding, and background, in more “traditional” CSS solutions, I'd have to copy all of those styles.

// somewhere far away from the Button
const somethingDifferentCss = css`
  display: flex;
  background: red;
  padding: 1rem;
  // all other very different CSS props
`;

const MyApp = () => {
  return (
    <div className={somethingDifferentCss}>
      I'm something different
    </div>
  );
};

There is no sane way to reuse them. As a result, there could be a lot of repetition in the CSS file.

With Tailwind, I'll use exactly the same class names on this completely different component:

// exactly the same classes on a completely different component
const MyApp = () => {
  return <div className="flex p-4 bg-red-500">I'm something different</button>
}

The CSS file, in this case, will stay as small as it can possibly be and will grow at a much slower pace than any “traditional” framework.

The downside here, however, is that classNames become long. Veeeeeeerery long sometimes. Compare, for example, how the code of the Login page looks when it's written in Linaria vs Tailwind.

What we're measuring

So, TL;DR; from the above: Tailwind tends to make CSS smaller and HTML larger. And we already know that the size of CSS and HTML can directly affect initial load performance.

So this is what I want to measure today:

How much smaller?
How much larger?
How much will the initial load change, and in which direction?

If you haven't done it already, now is the time to download and install the Tailwind baseline project and its conversion to Linaria.

Measuring the change in assets

The easiest thing to measure here is the size of the assets produced. So let's start with that.

Run npm run build on both projects and write down the numbers.

		Linaria	Tailwind	Difference
1	HTML	0.49 kB	0.49 kB	0
2	CSS	55.69 kB	48.25 kB	-13%
3	JavaScript	381.50 kB	394.63 kB	+3%

The HTML size didn't change at all, which is the very first lesson here. I forgot that we can render our app on the client and on the server, and the performance picture will be very different depending on the rendering method. I would need to test both of them.

The almost-zero HTML size is a clear indication that this app is Client-Side Rendered, those have just an empty div as HTML. Look into dist/index.html for both projects to see that they are indeed almost empty.

CSS is smaller by 13% with Tailwind, which is great, and indeed confirms our assumption. JavaScript is slightly larger, which, considering that all the long class names are buried in the JavaScript file, since we're writing React, is understandable. And also confirms our assumption in a way.

To measure the HTML increase, I need to render the React code on the server and save that as static files. Luckily, I already had a script from the last time that does exactly that, so it's not a problem. Just run npm run build:ssg for both projects, it will generate three HTML pages: index, login, and settings - one for each page. They will show up in the dist folder.

Find them there and write down their size:

		Linaria	Tailwind	Difference
1	HTML (client)	0.49 kB	0.49 kB	0
2	CSS	55.69 kB	48.25 kB	-13%
3	JavaScript	381.50 kB	394.63 kB	+3%
4	HTML index (SSR)	58.62KB	99.55KB	+70%
5	HTML login (SSR)	74.66KB	77.99KB	+4%
6	HTML settings (SSR)	37.45KB	98.27KB	+162%

The results are very interesting. Tailwind indeed exploded the HTML size in some cases. The Settings page more than doubled its size! Try comparing them between projects side-by-side to figure out why - it's a ton of fun.

And since we have those numbers, it's time to make an educated guess about the result. What do you think those changes in numbers will do for the initial load performance? Will it go up or down? Write it down!

We're going to be measuring LCP (Largest Contentful Paint) number for the Settings page, to make it simpler.

The logical assumption here would be:

In the “Client” mode, it will probably be slightly less for the Tailwind website, since the CSS file is smaller.
In the SSR mode, it will probably go up for Tailwind. Surely, the 162% increase in the initial HTML will be very visible and will counteract the 13% CSS improvement.

Curious, was your assumption different? If yes, time to find out who's right!

Measuring LCP in Client mode

Clean the dist folder and rebuild the project again, to get rid of the HTML pages we generated earlier. Then, inside your Tailwind-based project, serve the website like this:

 npm run preview

Then, open the website in Chrome, in incognito mode or guest profile, to eliminate the influence of installed plugins. Navigate to “Settings”, open the Performance panel in the Dev Tools, set 6x CPU throttling and Slow 4G network, enable the “disable cache” checkbox, and hit “Reload and Record”.

Write down the LCP number. Then do the same for the Linaria-based project and put the numbers into the table. For me, the results are this:

		Linaria	Tailwind
1	CSR, Settings page, LCP	2.36s	2.36s

Hmmmm. Zero gains from the CSS reduction. That is slightly disappointing. Plus, one of my predictions is wrong already 😭 I wonder why it happened?

The answer to this should be apparent if you look at the entire performance picture, not just the LCP number. If you've never read those graphs before, it's time to pause and read the guide on this topic first.

Both of the profiles are pretty much identical and look like this:

At first, there is an almost non-existent HTML download on the left in the “Network” section. The HTML file for the CSR is almost empty, so that checks out. Then, the download of CSS and JS files is triggered. CSS is render-blocking, as confirmed by the red corner, but the JS file is non-blocking. So technically, it shouldn't influence the initial render.

And it wouldn't, if we had at least something in our HTML file. However, it's empty. The browser has nothing to render - everything that we'd want to put on the screen is hidden inside the JS file. So we have no choice but to wait until it's ready. Only after it's downloaded, compiled, and executed do we see the beautiful Settings page, and the LCP metric is triggered.

So the JavaScript size is the bottleneck here, not CSS or HTML. And since it barely changed between the two projects (3% is nothing for those sizes), we see exactly zero difference between Tailwind and Linaria here.

The only time when the CSS size will make a difference is when the JS is not in the picture. Which means it's either completely slimmed down with code splitting/lazy loading, or when the HTML is not empty. I.e., the website is SSR.

Let's measure the CSS loading times and add them to the table to get the full picture.

		Linaria	Tailwind
1	CSR, Settings page, LCP	2.36s	2.36s
2	CSR, Settings page, CSS downloading time	659ms	660ms

Lol, there's still no difference. To understand why, take a closer look at the structure of the CSS bar. The actual “download time” part there is that tiny solid block at the very end. Which is just around 70ms long. The rest is latency.

Not to mention that we don't actually transfer all those 50-ish KB. If you look at the Network panel, you'll see something like this:

We have compression enabled by default for our local web server, and hopefully, your production server as well. The difference in this case in CSS is around 1KB between Tailwind and Linaria. No wonder it's not visible.

Let's try to run the same measurements with Network throttling set to 3G:

		Linaria	Tailwind
1	CSR, Settings page, LCP, 3G	7.5s	7.5s
2	CSR, Settings page, CSS downloading time, 3G	2.3s	2.3s

And the measurements are still identical. Looks like the CSS needs to be much larger to notice anything. We're talking about megabytes, not our measly 50-ish KB.

Okay, so exactly zero impact on performance so far. But that's CSR. What about SSR?

Measuring LCP in SSR mode

For SSR, the size of the initial HTML matters. Considering that the difference between the two versions here is 160%, I would expect to see it reflected in the performance numbers.

The easiest way to measure this is to generate the static pages again. We don't really need the “server” to be dynamic to measure the HTML download time.

So generate them for each project:

npm run build:ssg

Run again:

npm run preview

And record the performance again. This time, the profile will be different:

At first, there will be some proper HTML download, followed by the same JS and CSS bars. But then, after the CSS is finished, you'll see the Layout block in the “main” section, followed by the LCP metric. HTML was pre-generated, CSS is available, and the browser can show the page without waiting for the JS.

Write down the numbers again, including the HTML download time.

		Linaria	Tailwind
1	SSR, Settings page, LCP	1.4s	1.4s
2	SSR, Settings page, CSS downloading time	690ms	690ms
3	SSR, Settings page, HTML downloading time	612ms	614ms
4	SSR, Settings page, LCP, 3G	4.7s	4.7s
5	SSR, Settings page, CSS downloading time, 3G	2.5s	2.5s
6	SSR, Settings page, HTML downloading time, 3G	2.1s	2.1s

Funny how identical the numbers are, despite the raw HTML size being so different, right?

That's compression again. Text-based values, like CSS and especially HTML, with lots of repeating values, compress really well.

So the verdict here: the more non-Tailwind CSS or Tailwind HTML you have, the more repetitive it will be, and the better the compression will be. To actually see something meaningful, the difference between files needs to be really drastic, and the values probably should be in megabytes, not kilobytes.

Although I suspect that if your product grows to this size, you'll probably have better ways to noticeably improve its performance, like code splitting and lazy loading. Switching to a different CSS framework will be at the very bottom of the effort/gain list.

Measuring INP

Until this moment, I had measured only the initial load performance. The interaction performance was slightly forgotten. This is because both of the solutions produce your normal CSS in the end, and the styling for both projects is pretty much identical. So, I don't anticipate that anything can be different in that area.

However, this is just an assumption, and since all of my assumptions until now turned out to be incorrect, I definitely should check that one out.

To do that, I can measure what is known as INP. I.e., Interaction to Next Paint metric. To achieve what I want to achieve, I don't even need to know any details about that metric. All I really need to see is whether it's the same (I assume it will be) or not.

To do that, open the Performance panel in Chrome and interact with the page. Don't record anything, and clean up any recording that you have there. You should see a picture like this:

There will be an overall number, the longest interaction. And then the stream of interactions underneath - it records everything that you do on a page.

Let's, for example, record three things:

How long does it take to navigate between the "Settings" page and "Login" (click on the logo to get there).
How long does it take to open a "..." menu on the Home page.
In the "mobile" view, how long does it take to open the sidebar drawer by clicking on the "hamburger" menu.

I'll record the initial click for each of those. It seems to be the longest. And then the average value afterward. I'll also be recording them with a "low-tier" CPU throttling setting, otherwise the numbers are way too small.

Here are the results.

		Linaria	Tailwind
1	Navigate to Login	Longest: 131 Average: 88	Longest: 128 Average: 90
2	Open "..." dropdown	Longest: 192 Average: 114	Longest: 240 Average: 152
3	Open the sidebar drawer in the mobile view	Longest: 224 Average: 165	Longest: 256 Average: 178

Linaria

Tailwind

Navigate to Login

Longest: 131

Average: 88

Longest: 128

Average: 90

Open "..." dropdown

Longest: 192

Average: 114

Longest: 240

Average: 152

Open the sidebar drawer in the mobile view

Longest: 224

Average: 165

Longest: 256

Average: 178

Which is... weird. It seems like navigating to another page is more or less the same between the projects. But opening dropdowns and drawers seems to be noticeably slower in Tailwind? 🤔 Could it be some random fluctuation? Those INP numbers were really unstable compare to the network numbers.

To be absolutely sure, I run the measurements again on 20x CPU and an endless number of times. The absolute numbers still fluctuated greatly, but the trend was consistent: the Tailwind-based menus and drawers are slower.

This was an absolute table-flip moment for me. Not only every single one of my assumptions turned out to be wrong during this investigation. But the latest result just doesn't make sense. The UI is the same, the produced DOM elements are the same, styling is the same except for a few broken colors here and there. There is no possible way that result can be so different! WHAT IS GOING ON??

Let's think logically. First of all, I need to record the full performance profile for this interaction - maybe there is clue there. Click the "Record" button in the Performance profile, open the menu, stop the recording. Easy.

The result looks like this:

The exact names of functions here are jibberish, of course, and most of it is probably React internals. But it doesn't really matter since I know already how to interpret graphs like this. The important thing here is the longest bars at the bottom of a "flame" - those are the bottlenecks. In this case, there are two of them, both named "Recalculate style".

Both the Tailwind and Linaria projects have exactly the same overall structure, with exactly the same long "Recalculate style" bars. Only in the case of the Tailwind project, those bars are twice as long. 85ms + 72ms for the Tailwind project and 48ms + 40ms for Linaria.

Okay, so what exactly is this "Recalculate style" task? Quick googling reveals that this is when the browser iterates through DOM elements on a page and, you guessed it, recalculates their styles. It happens when something changes on a page, like an element is added or an attribute changes. So it makes a lot of sense that the browser does it when the dropdown opens: a new element is added.

What doesn't make sense is why it would be different for exactly the same dropdown? Even more reading shows that I can record which selectors were involved in this operation and how long it took. This seems like something helpful, let's try it!

Turning on the "Enable CSS selector stats" checkbox (it's hidden inside the Settings cog in the Performance panel), recording the same interaction, and peeking into the Selector stats tab at the bottom. For the Tailwind project:

and Linaria:

When sorted by "Match count", which is how many times the browser tried to apply a particular selector, it's very visible that the Tailwind project had twice as many attempts for ::after, ::before and * selectors as Linaria. Plus, there is a :backgrop selector that is just not present in the Linaria project.

This seems like a very likely reason for the difference. Clicking on the links in the Style Sheet table reveals that the Tailwind-based project has this in its CSS file:

*, :before, :after {
    --tw-border-spacing-x: 0;
    --tw-border-spacing-y: 0;
    // bunch of other --tw-prefixed stuff
}

::backdrop {
    --tw-border-spacing-x: 0;
    --tw-border-spacing-y: 0;
     // bunch of other --tw-prefixed stuff
}

Where * is a "universal" selector, i.e., it's applied to every DOM node. The same story is with :before, :after and probably :backdrop.

The Linaria-based project doesn't have any of those.

So theoretically, looks like it's very possible that the slowdown happens because of the additional selectors. I just need to verify it. The easiest way to do it is to copy-paste them manually to the pre-built index.css file of the Linaria project. The one inside dist/assets folder.

Then refresh the page, measure the same interaction, and voila! It's as slow as in the Tailwind project! 🎉 I can do a little dance here 💃🏻

The final step, before I can close this investigation, is to figure out where those selectors come from. There is nothing like this in the styles I wrote, so it has to come from Tailwind itself.

And indeed, a simple process of elimination proves that it's hidden inside @tailwind base; import. Non-fixable on my side in a sane way, it's an essential part of the framework.

Results of the investigation

So, to summarise, what exactly did I discover during this investigation?

Tailwind, indeed, makes CSS smaller and HTML/JS larger. The CSS decrease for my project was 13%, the JS increase was 3%, and HTML varied from page to page: 4%, 70%, 162%.

Those increases and decreases affected initial load performance in exactly zero way.

But interestingly enough, the performance of some interactions is worse with Tailwind, which was totally unexpected.

Does this mean that Tailwind is not a good choice for performance-conscious people? Absolutely not. It's totally fine, same as Linaria.

This slight degradation of interaction performance is, first of all, a bit of an edge case and likely can be improved by rewriting the JavaScript part of it. Recalculating styles was not the only thing in that profile.

Secondly, it was still in the "green" zone even for the "low-tier mobile" simulation. Only when I decreased the CPU to 20x did it become red. So I'd say it's something to keep an eye on if you're writing apps primarily for customers on very old phones and very bad network connections. But for the rest of us, it's unlikely to be a blocker for anything.

So, to answer the question from the beginning: what to choose for your new project, Tailwind or Linaria? Choose whichever dev experience you like the most. Or which is better maintained. Or which changes its API less. Or whichever is not owned by an Evil Corp of the month. Or any other reason you use to evaluate new libraries and frameworks.

From a performance perspective, you're likely fine with both of them for a very long time.

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter or Bluesky to get notified as soon as the next article comes out.

SSR Deep Dive for React Developers

Nadia Makarevich — Thu, 20 Mar 2025 10:21:00 +0000

This is the third article in the series "Web Performance Stuff for React Developers." In the previous articles, we learned the basics of performance metrics for measuring initial load, what CSR (Client-Side rendering) is, why it’s so popular, and how to record, read and interpret the performance Flame Chart. We also learned two of the most significant downsides of Client-Side Rendering: it negatively affects the initial load and doesn’t work in environments without JavaScript.

In this article, we’re going to focus on solving those downsides by introducing another rendering pattern called SSR (Server-Side Rendering) and its variations like pre-rendering and SSG (Static Site Generation). We’ll again have a Study Project, with the help of which we’ll implement the simplest pre-rendering for a beautiful website, take a look at the cost of it and what it solves, then implement a proper SSR for it, measure its performance impact, talk about the cost of SSR, and finish with a quick implementation of SSG for the website.

Going to be exciting!

Why no-JavaScript environments are so important

Let’s start with no-JavaScript environments. This might be the most puzzling downside. Who disables JavaScript these days in their browser? It’s enabled by default everywhere, pretty much nothing will work without it, and most people won’t even know what JavaScript is to disable it anyway. Right?

The answer here is in the word “people.” Or, more precisely, in the fact that the real people are not the only ones who can access your website. Two major players in this area are:

Search engine robots (crawlers), especially the Google crawler.
Various social media and messengers “preview” functionality.

All of them work in a similar manner. First, they somehow get the URL to your website’s page. This usually happens either when a user tries to share a link to your page with their social media friends. Or when a search bot mindlessly crawls through the millions and millions of publicly available pages online. That’s why they are called crawlers btw.

Second, the bots send the request to the server and receive the HTML - just like the browser does at the very beginning.

Third, from that HTML, they extract the information they came for and process it. Search engines extract stuff like text, links, meta-tags, etc. Based on that, they form the search index, and the page becomes “googleable”. Social media previewers grab the meta-tags and create the nice preview we all have seen, with a large picture, title, and sometimes a short description.

And finally, fourth… Actually, there is no fourth sometimes. That’s it. No JavaScript, just pure HTML. Because rendering the page properly with JavaScript means the robots need to spin up an actual browser, load JavaScript, and wait for it to finish generating the page. Which is quite costly from the resource and time perspective. So not all of them can do it.

You can see it in action in the Study project. Download it and install dependencies:

npm install

Then build and start:

npm run build
npm run start

Navigate between Home and Settings there. You should see that the title of the page changes with navigation. “Study project: Home” for the home page and “Study project: Settings” for settings.

This title is injected with React with a simple code like this:

useEffect(() => {
  updateTitle('Study project: Home');
}, []);

Where inside, it’s just this:

export const updateTitle = (text: string) => {
  document.title = text;
};

However, you also should see that it briefly “flashes” when initially loaded - that’s because the default title is “Vite + React + TS”: this is the title I have in index.html, and as a result, this is the title I receive from the server.

Now, expose the website to the outside world with ngrok (or a similar tool if you have it):

ngrok http 3000

Any try to post the URL it generates for you on the social media of your choosing. In the generated preview, you’ll see the old “Vite + React + TS” title. No JavaScript was loaded.

Although, this is not entirely true for some of the bots. Most of the popular search engines do wait for JavaScript. Google, for example, has a two-step process where it parses the “pure” HTML and also puts the page into a “render” queue, where it actually spins up a browser, loads the website there, waits for JavaScript rendering, and extracts everything it can again.

However, this process means that the indexing of a website that relies heavily on JavaScript might be “slower and budgeted”.

So if for your website it’s:

Mission-critical to be discoverable by as many search engines as possible as fast as possible.
It’s crucial to be shareable on social media platforms and to look good in the process.

Then it’s very important for the server to return the “proper” HTML with all the critical information on the very first request. Typical examples of such websites are:

Read-first websites, i.e., various forms of blogs, documentation, knowledge base, forums, Q&A websites, news outlets, etc.
Various forms of e-commerce websites.
Landing pages.
And so on - pretty much everything that you can search for on the World Wide Web.

That means that the “classic” client-side rendered SPA, with its empty div as the first HTML response, is a bad idea here.

It doesn’t mean, however, that we need to throw away React in anger. There are a few solutions we can try first.

Server pre-rendering

For this one, we’d need to introduce a server into the equation. Right now, in the study project, it looks like this:

app.get('/*', async (c) => {
  const html = fs
    .readFileSync(path.join(dist, 'index.html'))
    .toString();

  return c.html(html);
});

When the server receives any request, it just reads the index.html file that the build step generated for us in advance, converts it into a string, and sends it back to whoever requested it. It’s basically what all hosting platforms that support SPA will do for you. It’s just not something we directly control or modify with platforms like this.

However, to fix the “no-JavaScript” problem, we need to modify the server now. Fortunately, not much. The fact that it’s just a string we’re working with, simplifies matters a lot. Because nothing stops us from modifying this string before sending it back. Let’s find the existing title and replace it with “Study project,” for example:

app.get('/*', async (c) => {
  const html = fs
    .readFileSync(path.join(dist, 'index.html'))
    .toString();

  const modifiedHTML = html.replace(
    '<title>Vite + React + TS</title>',
    `<title>Study project</title>`,
  );

  return c.html(html);
});

That’s slightly better, but in real life, the title should change for every page: there's no point in keeping it static like this. Luckily, each server always knows exactly where the request is coming from. For the framework that I’m using (Hono), it’s a matter of asking for c.req.path to extract it.

After that, we can generate different titles based on that path:

app.get('/*', async (c) => {
  const html = fs
    .readFileSync(path.join(dist, 'index.html'))
    .toString();

  const title = getTitleFromPath(pathname);

  const modifiedHTML = html.replace(
    '<title>Vite + React + TS</title>',
    `<title>${title}</title>`,
  );

  return c.html(html);
});

Where in getTitleFromPath we can do something like this:

const getTitleFromPath = (pathname: string) => {
  let title = 'Study project';

  if (pathname.startsWith('/settings')) {
    title = 'Study project: Settings';
  } else if (pathname === '/login') {
    title = 'Study project: Login';
  }

  return title;
};

In real life, this might need to be co-located with the actual pages or even extracted from the page code itself - otherwise, it will go out of sync with them almost immediately. But for the study project, this will do just fine.

One last thing to make it pretty: in the index.html file, we can replace the original title <title>Vite + React + TS</title> with something like <title>{{title}}</title> and turn it into a template.

<html lang="en">
  <head>
    <title>{{ title }}</title>
  </head>
  ...
</html>;

// on the server then do this instead:
const modifiedHTML = html.replace('{{title}}', title);

In the future, we can convert it into any of the templating languages if there is a need.

And, of course, we’re not limited by only the title tag - we can pre-render all the information in <head> like this. This gives us a relatively easy and cheap way to solve the “no-JavaScript” problem for social media preview functionality. They usually don’t need more. Most of them rely on the Open Graph protocol, which is just a bunch of <meta> tags with information.

We can even pre-render the entire page, not only meta-tags! But that one we’ll cover in the separate SSR block below, there are many more things to learn there.

Additional Challenge

In backend replace the contents of the index file with the content of backend/pre-rendering-index.ts
In src/index.html replace the contents of the title tag with {{ title }}
Refactor both the frontend and backend code to support the required meta-tags for social media sharing (see
the list here)
Build the project, expose it via ngrok again, and try to share each page (login, home, settings) on the social media of your choosing. The preview should work properly now and show the details of each page.
Bonus question: How would you refactor the project so that the meta-tag information is not duplicated between the Client and the Server?

The cost of server pre-rendering

I mentioned above that the meta-tags prerendering is relatively cheap. What exactly does this mean, though? How cheap, especially compared to the price and effort before introducing it?

Unfortunately, there is no good news compared to the completely static SPA. By adding a simple pre-rendering script, I introduced two problems other than the obvious increase in complexity that I now have to deal with.

Where to deploy?

The very first problem is, where should I deploy the app now? Before the change, I could keep the hosting cost at zero for a very long time - hosting static resources is extremely cheap these days. Now, I need to have a server. And those usually ain’t cheap.

There are two most common solutions here.

We can use the serverless functions of the hosting provider that serve the static resources: Cloudflare Workers, Netlify Functions, Vercel Functions, Amazon Lambdas, etc. Most of the static resource hosting providers probably have them in one form or another.

The advantage here is we still don’t need to think about the server and its maintenance. Those Cloud Functions are like mini-servers that the provider deals with for us. Our job is to write code, and it magically Just Works. Everything else is their concern. For study projects, some niche projects, projects at the very beginning of their journey, and those that don’t have a viral nature built-in, cloud functions will be the optimal choice.

Cloud functions are usually very easy to configure and deploy, they are priced per usage, and the usage comes from actually hitting the endpoint. There is no chance of incurring an unexpected bill here by accidentally leaving the container running over the weekend.

The downside is the “price per usage” part. The more popular the website is, the more chances that the usage will exceed the limits. I read a few horror stories where a project became popular on HackerNews or TikTok, suddenly got a few million visitors instead of the regular hundred, and the owner woke up to a surprise $5000 bill. So, setting spending limits, monitoring spending closely, and having a plan for what to do in this situation are crucial when it comes to serverless solutions.

If serverless functions are not your choice, you can just keep it as an actual tiny node (or anything else) server and deploy it to any cloud platform, from AWS to Azure to Digital Ocean to [insert your favorite hosting provider].

This solution has its advantages. Everything is under your control. Migrating from one solution to another won’t require code changes, as opposed to serverless functions, which are vendor-locking you a bit. Prices are usually much more predictable, much simpler, and much lower when the usage increases. Also, you can use whatever tech stack you want, whereas serverless functions are usually very limited.

The disadvantages are exactly the same as the advantages. Everything is up to you now. You need to monitor CPU/memory usage. Worry about observability. Worry about scaling. Memory leaks will keep you up at night.

And you’ll have to worry about geographic regions. Which leads me to the second problem that arises with introducing any kind of server to a previously pure SPA app.

Performance impact of having a server

Remember the Initial Load article and the impact of latency and CDN on initial load performance? By introducing even a rudimentary server that only pre-renders meta-tags, I’m introducing a mandatory non-cached unavoidable round-trip to the server for every initial load request, regardless of whether the user is new or repeating.

I just made the initial load performance of an SPA app, which was never great to begin with, slightly worse. And how much worse will depend a lot on where exactly the server is deployed.

If it’s deployed as one of the Serverless Functions, then there is a chance that it's not that bad. Some of the providers can run those functions “on Edge.” I.e., those functions are distributed to different servers that are closer to the end user. Pretty much the same as CDN for static resources. In this case, the latency will be minimal, and the performance degradation will be minimal.

If, however, I went with the self-managed server, I don’t have the advantages of a distributed network. I’d have to deploy it to one particular region. So, users on the opposite side of the planet from this region have a chance to really feel the impact of the performance degradation.

If this performance impact is critical, you’d have to deal with it somehow. Prepare yourself for complicated caching strategies, deployments to different regions, etc. Basically, it’s not a simple no-server frontend app anymore. It’s a full-stack or even backend-first app now.

Next.js on Vercel/Netlify

A question that immediately might pop into mind: “I’m just writing my frontend with Next.js and deploying it to Vercel/Netlify. Do I really need to know any of this?”

The answer here is, “Unfortunately, yes, you can’t escape it.” Because, that’s exactly what those Next.js-first hosting providers do by default: they convert your app into JavaScript files and a bunch of small Serverless Functions. It’s just happening without your control or even knowing about it.

So unless you’ve explicitly set up your Next.js project to export as “static,” everything in “The cost of server pre-rendering” applies.

Additional Challenge

If you have a Next.js app that is “natively” deployed (i.e. 1-click deployment) to some serverless platform like Vercel/Netlify, try to find how many functions were created for it.
Are those “edge” functions or normal functions? Can you find out how usage is calculated for them? How many visitors can your website handle before you’re over the limit?
If you have a combination of “normal” and “edge” functions - can you map out which function is responsible for what, and what effect they have on your deployed project?

Pre-rendering the entire page on the server (SSR)

Let’s talk about pre-rendering some more. In the section above, we pre-rendered only meta-tags because it was easy just to replace an existing string with another string. But what stops us from messing around beyond the <head> tag? Let’s take a look at the contents of the <body> tag of our HTML page that is sent by the server:

<body>
  <div id="root"></div>
  <script type="module" src="./main.tsx"></script>
</body>

Remember how Client-Side rendering works? When the scripts are downloaded and processed, React takes the “root” element and appends the generated DOM elements to it. So what would happen if, instead of the empty div, I returned a div with some content inside? Let’s make it a big red block:

<div id="root">
  <div style="background:red;width:100px;height:100px;">
    Big Red Block
  </div>
</div>

Try adding it to the index.html, build the project, start it, and don’t forget to disable the cache and slow down the CPU and Network for better visibility.

When you refresh the page, you should see the momentary flash of the Big Red Block, which is replaced by the normal dashboard page. The first great news is that the red block didn’t stick around - obviously, React clears the “root” div before inserting anything inside. Or overrides the existing children, doesn’t matter for this article.

The second great news comes from staring at the performance graph. Record it now. The result should be something like this:

Pay special attention to the order of things and timing here.

In the beginning, it looks exactly like the graphs we’ve seen before. First, waiting for HTML from the server which results in a blue HTML parsing block in the “main” section. That one triggered the download of CSS and JavaScript (yellow and purple blocks in “Network”) at some point.

But after the CSS was done downloading, different things started happening. First, we see a somewhat longer block of purple “Layout” (same level as the blue HTML block). That didn’t happen before! Almost immediately after it was done, the FCP (First Contentful Paint) was triggered. But the JavaScript bar at the top is still loading! After that, things continue as usual - JavaScript finishes loading, it’s processed, painted, and then LCP (Large Contentful Paint) is triggered.

If you hover over the very top section, where the screenshots of the frames appear, you’ll see that the gap between FCP and LCP is exactly the period when our Big Red Block was present on the page. The gap between the FCP and LCP for me is around 500ms, with FCP around 800ms and LCP around 1.3s.

Looks like this 500ms is pretty much the cost of Client-Side rendering for the initial load. This is huge! If I somehow manage to shave off those 500ms from LCP, that’s a 40% improvement! I might get a promotion for this.

Fortunately, everything is possible. React gives us a few methods that can pre-render the entire app and which we can theoretically use here. For example, there is “renderToString.” It can render our app into a string, according to the documentation:

const App = () => <div>React app</div>;

// somewhere on the server
const html = renderToString(<App />); // the output will be <div>React app</div>

Since we’re already dealing with strings on the server, this seems perfect. All that I’d need to do is to replace the empty “root” div with the output of this function. Exactly the same as we did for meta-tags. Let’s try?

Go to the backend/index.ts and clean it up from any modification we did above. Find the commented-out code:

// return c.html(preRenderApp(html));

And uncomment it. Re-record the performance again. The end result should be something like this:

The difference is immediately visible: FCP and LCP happened at the same time. Before the main React-produced JavaScript was triggered and even before JavaScript finished loading. That means that content pre-rendering is working! 🎉 Happy days ☀️☺️. Hover over the screenshots at the very top to verify that it is indeed the beautiful dashboard that showed up then, not some random fluctuation.

There is, however, a tiny abnormality - the FCP is triggered later than I promised. I was hoping to see it at 800ms, but it is actually around 900ms. The recurring lesson in everything performance: never promise exact numbers in advance 😅. But where did I lose 100ms?

First of all, look at the very top left corner, the “Network” section, where we have the initial request to the server. Notice the solid blue line there appearing? This is our HTML content downloading. We’re sending many more elements now, not just a simple empty <div>. Hover over that block to see the exact numbers - around a third of the missing 100ms is spent on downloading the content.

Also, pay attention to the purple “Layout” block after the “Parse HTML” task. It looks much longer, isn’t it? Hover over it again for the exact numbers - and here’s your missing two-thirds of the 100ms. The browser needed not only to download some extra HTML but also to calculate the positions of many more elements before painting them.

Hence the missing time. But still worth it, isn’t it? I shredded 400ms from the LCP timing and improved initial load performance by 30%! And here’s another cool part: disable JavaScript now and refresh the page. The dashboard is still there! And even links work, although they cause the full reload.

This part is what makes SSR worthwhile. Now, every search engine and every other robot that you want to give access to your page will see everything without loading any JavaScript. Performance improvement here is a nice bonus. And an unstable one at that.

SSR can make initial load worse

Unstable, because there are no silver bullets in performance. If someone tells you SSR will a 100% increase the initial load of your SPA app, they are mistaken. Now that you know how network conditions, Client-Side and Server-Side rendering work, can you think of a scenario when SSR worsens LCP?

Here’s how.

Disable the CPU throttling, let your machine be fast again. Set Networking to the slowest possible simulation. For me, default Chrome 3G does the trick, but you might need to go slower - it will depend on how fast your machine is. Uncheck the “disabled cache” checkbox. I want those CSS/JS files to be served from the browser memory.

Now, measure the LCP with and without pre-rendering.

For me, the results are like this. Without pre-rendering, the “SPA” mode, the LCP is around 2.13 seconds. With pre-rendering, the “SSR” mode it’s around 2.62 seconds. Almost 500ms longer!

The performance charts are a fascinating read for this situation as well. The “SPA” mode looks like this:

At first, there is a loooong block (2 seconds) of waiting for the server’s response in the Network section. That’s the latency of the slow network connection. Then, almost instantaneous access to JavaScript and CSS resources: they come from the browser cache, no network. Plus, almost instantaneous download of the HTML content - it’s just an empty div. Then, the regular and quite fast, since the CPU is not slowed down, JavaScript execution. That’s our React generating the page. And finally, the page is visible.

Now, the same Network/CPU conditions with the SSR mode enabled:

Same initial waiting time - latency never went away. Then, HTML starts downloading. But since now we have a lot of it, the download now takes a looooooong time - the bandwidth is very reduced.

Then the most fascinating part: while the content is downloading, I see spikes of activity in the Main section. Enlarge and hover over them - it will be mostly Layout tasks. The browser already has CSS and JavaScript downloaded (from the cache), so it has all the necessary information to paint the layout as soon as it gets small pieces of it. And it does.

You should be able to actually see the gradual build-up of the interface on the page: first, the sidebar shows up, then the top nav, then the top charts, then the table. All of this is in the order of the HTML that is coming through slowly. If this is not cool, I don’t know what is.

While this example feels like a weird edge case, it’s actually not. The combination of a slow network + huge latency + fast laptop happens quite often for business travelers, for example. Or wildlife photographers. Or travel bloggers. Or engineers sent to remote locations. So if your app is targeting that specific niche primarily, and your app is already SPA, trying to introduce SSR to it might make it worse.

Or it might not, of course. It will depend on the size of the HTML that is downloaded, how fast the devices actually are, and how much JavaScript the app needs to render. Essentially, it all comes down to two things: knowing your customers and measuring, measuring, measuring everything.

SSR and hydration

In all this excitement about showing the content sooner, we forgot to investigate what happens after the content is loaded.

Remember the Big Red Block behavior? After React has loaded and generated its own elements, it completely replaced the content of the “root” div and everything inside, including the Big Red Block. But what happens when, instead of the weird red block, I send the actual HTML of the future page?

Actually nothing. I haven’t told React in any way that this content is important, so it will behave in exactly the same way: clear the entire content of the “root” div and replace it with its own. It just happens to be exactly the same content from the HTML perspective, so we don’t see the difference with the naked eye.

But we can see it in the performance profile. Slow down the CPU and Network to make the behavior slightly more visible and re-record the performance for the SSR example. Pay attention to what is happening after the CSS and JavaScript received:

On the top left, I have the network section, where the resources are finished downloading. Almost immediately after the CSS is received, I see a large purple “Layout” section below - that’s when our SSR’d content shows up. After the JavaScript yellow block on the top left finished loading, React kicks in. The somewhat longer task (180ms) is when React builds the UI. At the very bottom right, I again see a small-ish Layout block.

This is a typical picture of the Client-Side Rendering that we’ve seen many times already. This is when React clears the “root” div and injects whatever it generates instead. And also, it’s completely unnecessary. React already has all the DOM elements present, it could’ve just reused them instead. Surely, it should be faster.

This is when what is known as “hydration” comes in. “Hydration” does exactly what I wished for above - it shows React that there is already HTML on the page that matches exactly the HTML it will generate. So React can just re-use the existing DOM nodes, add event listeners to them, prepare whatever it needs internally for future functionality and call it a day. No unnecessary mounting components from scratch!

Hydration in React is actually very simple to implement, for once: it’s just one function call. All we need to do is to replace the createRoot entry point with this:

hydrateRoot(
  document.getElementById('root')!,
  <StrictMode>
    <App />
  </StrictMode>,
);

You can find this code in src/main.tsx - comment out the createRoot part and uncomment the hydration part. Then re-build and re-start the project:

npm run build
npm run start

Measure the performance again:

There is no more purple stuff in the React-related JavaScript execution. And it’s slightly faster now - 142 ms instead of 180. This might not seem as much now, especially considering that LCP was triggered before. But it’s not always going to stay like this.

Try, for example, unchecking the “disable network cache” and removing Network throttling while keeping the CPU down. Emulating repeated visitors with fast internet but slow devices. For me, without hydration, it separates FCP from LCP and pushes the LCP beyond the JavaScript task at the very end. LCP, in this case, is around 550ms. With hydration enabled, LCP moves closer to FCP and hovers around 280ms, right at the beginning of the JavaScript task.

There is also a matter of blocking the main thread and reducing it as much as possible, which Hydration helps with. Also, Hydration is not only about JavaScript listeners. It also allows fetching and injecting some initial data into the app - so we can avoid loading spinners or flashes of content. But about that, maybe in another article in the future.

Should I implement SSR like this?

Now that it seems obvious that SSR might be very, very useful for certain cases, and implementing it seems kinda trivial, the question might arise: can I just use the code from the study project and implement my own SSR?

The answer will be very rare for this blog: absolutely not! This solution is fine for study purposes, to explore how pre-rendered content behaves from different perspectives while turning on and off one thing.

But it’s actually not trivial at all. I hid half of the things I had to do to make it work. Half of the things have not been implemented yet. It’s a very basic and almost deprecated version on the backend that doesn’t support the latest React features.

First of all, there is no SSR for the dev server here. So, there is no way to debug the SSR other than constantly re-building the project. That’s half the reason you had to re-build it all the time to apply changes, by the way. (The other half is because performance should always be measured on the production build, so I don’t feel particularly guilty about it).

If you want nice things like hot reload, then you have to implement it by yourself. There is a whole large set of instructions on how to integrate SSR with Vite properly. And that’s Vite, for Webpack it will be very different and likely not very well documented. For something more exotic, I don’t even know where to start.

Second, the pretty string const html = renderToString(<App />); that I showed from the React docs is a myth and is never actually going to work. The problem here is this part - <App />. This is JSX, it’s how we write React code most of the time, so it seems so normal now. But the only reason why it works is because your build system has a transformation step that is likely (or maybe not, it always depends) powered by Babel. “Pure” node or any other server framework won’t support it.

Look into backend/pre-render.ts to see how it’s actually implemented.

First, I extracted the transformed App code from Vite itself:

const { default: App } = await vite.ssrLoadModule('@/App');

If you’re on Webpack, you’ll likely need to manually configure and register Babel plugins for that. So, even the very first step would mean you need to have an understanding of what is happening here and how to implement it for your app.

The second step, the actual renderToString:

const reactHtml = renderToString(React.createElement(App, { ssrPath: path }));

Still doesn’t look like the docs - JSX support for the actual backend file is not the same as extracting it from Vite. Although, if you read the docs, you’ll notice that renderToString doesn’t support streaming and waiting for data.

So, to actually implement proper SSR, you’d need to understand whether you need those new features in your app or not. And if yes, how to implement them on the backend. There is some documentation for the recommended method and also a few discussion threads on Github on the topic, so at least it’s a start.

But it’s a lot of work, the things mentioned are just the beginning, and before you know it, you’re three months behind on the project and basically implementing your own Next.js. Why do you think there aren’t that many competitors to it?

So, unless there is a very valid business reason and a lot of support in terms of time, resources, and expertise for this, it might be easier just to use an already existing SSR framework. Especially considering that the backend part here is only one piece of the puzzle. There is also a lot of complexity involved on the front side.

SSR and frontend

Depending on the size of the app and how optimized it is for SSR, it actually might be even more complicated than the backend part. Yep, you heard me right, that’s another thing I hid from you while implementing the SSR above: we actually need to make changes to our frontend code as well.

Browser API and SSR

Remember how I got the HTML that is sent to the browser? I just generated a string with React’s renderToString and then injected that string into another string. There was no browser in the vicinity of this process and never will be.

So, what do you think will happen to all the calls to the browser variables that we so used to on the frontend? All those window.location and window.history and document.getElementById? Nothing good. window, document, etc., will turn into undefined. There is no browser that can inject them into the global scope.

So the second React tries to call a function (i.e., render a component) that tries to access them directly, it will fail with the window is not defined error. The entire app will just explode. Not just explode. The server part will explode, which is even worse - there won’t be any chance for the frontend part to catch the error and show some pretty screen with “we’re working on it, here’s a cookie.” Error handling would need to be handled on the server, and you’d have to have a special “server” error screen.

Additional Challenge

Try to add a simple console.info(window.location); to any part of the frontend code, for example, here: src/App.tsx
Re-build the app with npm run build and re-start it
You should see the Internal Server Error string on the screen
Can you come up with a way to fix it?

A typical way to fix it would be to check whether the window (and all others) global variable is declared before trying to access it:

if (typeof window !== 'undefined') {
  // do something when the global window API is available
}

If you look at the code in frontend/utils/use-client-router.tsx, this is exactly what I had to do. And would have to do any time I need to access window, document, or anything else at runtime.

useEffect and SSR

And speaking of use-client-router file. If you look closely, you’ll see that I didn’t have to do that check for typeof window inside useEffect:

useEffect(() => {
  const handlePopState = () => {
    setPath(window.location.pathname);
  };
  window.addEventListener('popstate', handlePopState);
  return () =>
    window.removeEventListener('popstate', handlePopState);
}, []);

It’s because when running on the server (i.e. via renderToString and friends), React doesn’t trigger useEffect. And useLayoutEffect, for that matter. Those hooks will be run only on the client after the hydration happens. Take a look at this short explanation and some lengthy discussion on the topic from the core React team members if you want more details on the reasoning for this behavior.

So it’s definitely something to keep in mind in case you’re expecting some UI changes as a result of useEffect - they will cause a “flash” of content when the JavaScript is loaded.

Conditional SSR rendering is a big no

Some parts of your code might have so many dependencies on the browser API that you might think it’s easier just to skip rendering that part entirely while in SSR mode. So the natural temptation would be to do something like this:

const Component = () => {
  // don't render anything while in SSR mode
  if (typeof window === "undefined") return null;

  // render stuff when the Client mode kicks in
  return ...
}

Nope. That’s not going to work. Or, more precisely, it will. But it will confuse React - it will expect that the HTML produced by the “server” code is exactly the same as the HTML produced by the client code.

It will confuse it so much that it will just fall back to the Client-Side Rendering pattern - where it will erase the entire content of the “root” div and replace it with the freshly generated elements. It will behave like the hydration never happened, with all the downsides that come from that.

Additional challenge:

Somewhere in frontend/pages/dashboard.tsx (or anywhere else you like) create a ClientOnlyButton component with the code:

const ClientOnlyButton = () => {
  if (typeof window === 'undefined') return null;
  return <button>Button</button>;
};

Render it somewhere on the page.
Re-build and re-start the project as usual.
Record the performance profile. It should show the picture we saw when hydration was not implemented yet, with Layout blocks inside the React JavaScript task.

Disappeared hydration - if you’re lucky! Sometimes it can introduce really weird layouting bugs instead, so the website will look completely broken.

The correct way to do it is to rely on React’s lifecycle to “hide” the non-SSR compatible blocks. For this, we need to introduce state and track in it whether a component is mounted or not:

const Component = () => {
  // initially it's not mounted
  const [isMounted, setIsMounted] = useState(false);
};

Then flip this state into true when a component has been mounted, i.e. inside a useEffect:

const Component = () => {
  // initially it's not mounted
  const [isMounted, setIsMounted] = useState(false);

  useEffect(() => {
    setIsMounted(true);
  }, []);
};

Remember: useEffect doesn’t run on the server, so the state will turn true only when the client-side version of the website is fully initialized by React.

And finally, render what we wanted to render that is not SSR compatible:

 const Component = () => {
  // initially it's not mounted
  const [isMounted, setIsMounted] = useState(false);

  useEffect(() => {
    setIsMounted(true);
  }, []);

  // don't render anything while in SSR mode
  if (!isMounted) return null;

  // render stuff when the Client mode kicks in
  return ...
}

Additional Challenge

Re-write the ClientOnlyButton from the previous exercise to work correctly with SSR.
Re-build and re-start the project as usual.
Record the performance profile. It should revert back to the SSRed look.

Third-party libraries

Not all of your external dependencies will be supportive of SSR. It’s always a gamble with the libraries. For some of them, you’ll be able to opt-out of the SSR using the solution above. Some of them will be rejected by the bundler, so you’d have to import them dynamically after the client-side JavaScript is loaded. Some of them you’d need to remove from the project and replace with a more SSR-friendly library.

This is going to be especially painful if the non-SSR-compatible library is something fundamental for the entire project. Like a state-management solution or a CSS-in-JS solution.

For example, try to use Material UI icons somewhere in the Study project:

// anywhere, for example in src/App.tsx
import { Star } from '@mui/icons-material';

function App() {
  // the rest of the code is the same
  return (
    <>
      ...
      <Star />
    </>
  );
}

Re-build it and start it - you should see that the SSR collapsed with:

 [vite] (ssr) Error when evaluating SSR module @/App: deepmerge is not a function

Have fun figuring out how to fix it 😬

Static Site Generation (SSG)

Okay, let’s assume that we’re absolutely have to have “proper” server-rendered pages and we’re ready to deal with the consequences on the frontend for this. For example, we’re implementing a fancy “promo” website. Those obviously need to be indexed by all possible search engines as fast as possible and should be shareable via everything that can share a link. That’s the whole point of a website like this.

Let’s also assume that all the info on the website is “static”, i.e. there is no user-generated content, no permissions to take into account, no complicated data generation per request. The website is just a few pages that introduce the product, some standard pages like “Terms and Conditions”, and a blog that is updated once a week.

This situation is a rare use case when we can have our cake and eat it too. We already know that pre-rendering the website on the server is relatively easy. It’s just a matter of calling React.renderToString on our app (more or less).

So the big question here is: what stops us from running React.renderToString during build time, right after we run npm run build? In theory, we’re pre-rendering and sending a proper HTML page to the browser anyway. And the pre-rendered content is always the same. We probably can just do it in advance, save it as a bunch of actual HTML files, like in good old times, and save ourselves the pain of having a “proper” server. Right?

The answer: there is absolutely nothing that stops us from doing that. Try running this:

npm run build:ssg

It will first build our website the usual way with Vite, and then run a very primitive script (backend/generate-static-pages.ts) that replaces the empty <div id="root"></div> with the content generated by renderToString. Exactly what the server does. Only now do we not need the server anymore.

Take a look at the built files in the dist folder. You’ll see two additional files now: login.html and settings.html. Open any of the HTML files - you’ll see that <div id="root"> is filled with content.

This is our “static” website, that we can start with absolutely any webserver:

npx serve dist

Or upload it pretty much anywhere, same as any Client-Side Rendered app. Only this time it won’t have CSR downsides, all search engines will be able to index it properly right away, and social-media shares will work beautifully.

Static websites are so good that they even have their own three-letter abbreviation: SSG (Static Site Generation). And of course, there are plenty of frameworks that generate them for you, no need in manual labour: Next.js supports SSG, Gatsby is still pretty popular, lots of people love Docusaurus, Astro promises the best performance, and probably many more.

There is still a lot to say about SSR, the concepts here are just a foundation to build upon. But hopefully, it was useful and you’ll feel more confident next time you need to make a decision: should we start with SSR for our next website or not?

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter or Bluesky to get notified as soon as the next article comes out.

[Boost]

Nadia Makarevich — Fri, 31 Jan 2025 09:17:29 +0000

Initial load performance for React developers: investigative deep dive

Nadia Makarevich ・ Jan 27

#webdev #javascript #webperf #performance

Initial load performance for React developers: investigative deep dive

Nadia Makarevich — Mon, 27 Jan 2025 09:04:00 +0000

Introducing initial load performance metrics
Overview of the performance DevTools
1. Setting up the project
2. Exploring the necessary DevTools
Exploring different network conditions
1. Very slow server
2. Emulating different bandwidth and latency
3. The importance of CDN
Repeat Visit Performance
1. Controlling Browser Cache with Cache-Control Headers
2. Cache-Control And Modern Bundlers
3. Do I really need to know all of this for my simple use case?

These days, with AI-driven code generation booming, the importance of writing React code is shrinking. Anyone and anything can write apps in React now. But writing code has always been just one part of the puzzle. We still need to deploy our apps somewhere, show them to users, make them robust, make them fast, and do a million other things. No AI can take over those. Not yet, at least.

So, let's focus on making apps fast today. And to do that, we need to step outside of React for a while. Because before making something fast, we first need to know what "fast" is, how to measure it, and what can influence this "fastness".

Spoiler alert: there will be no React in this article other than the study project. Today is all about fundamental stuff: how to use performance tools, an intro to Core Web Vitals, Chrome performance panel, what initial load performance is, which metrics measure it, and how cache control and different networking conditions influence it.

Introducing initial load performance metrics

What happens when I open my browser and try to navigate to my favorite website? I type "http://www.my-website.com" into the address bar, the browser sends a GET request to the server, and receives an HTML page in return.

The time it takes to do that is known as "Time To First Byte" (TTFB): the time between when the request is sent and when the result starts arriving. After the HTML is received, the browser now has to convert this HTML into a usable website as soon as possible.

It starts by rendering on the screen what is known as the "critical path": the minimal and most important content that can be shown to the user.

What exactly should be in the critical path is a complicated question. Ideally, everything so that the user sees the complete experience right away. But also - nothing, since it needs to be as fast as possible since it's a "critical" path. Both at the same time are impossible, so there needs to be a compromise.

The compromise looks like this. The browser assumes that to build the "critical path," it absolutely needs at least those types of resources:

The initial HTML that it receives from the server - to construct the actual DOM elements from which the experience is built.
The important CSS files that style those initial elements - otherwise, if it proceeded without waiting for them, the user would see a weird "flash" of unstyled content at the very beginning.
The critical JavaScript files that modify the layout synchronously.

The first one (HTML) the browser gets in the initial request from the server. It starts parsing it, and while doing so extracts links to the CSS and JS files it needs to complete the "critical path". It then sends the requests to get them from the server, waits until they are downloaded, processes them, combines all of this together, and at some point at the end, paints the "critical path" pixels on the screen.

Since the browser can't complete the initial rendering without those critical resources, they are known as "render-blocking resources". Not all CSS and JS resources are render-blocking, of course. It's usually only:

Most of the CSS, whether it's inline or via <link> tag.
JavaScript resources in the <head> tag that are not async or deferred.

The overall process of rendering the "critical path" looks something like this (roughly):

The browser starts parsing the initial HTML
While doing so, it extracts links to CSS and JS resources from the <head> tag.
Then, it kicks off the downloading process and waits for blocking resources to finish the download.
While waiting, it continues with processing HTML if possible.
After all the critical resources are received, they are processed as well.
And finally, it finishes whatever needs to be done and paints the actual pixels of the interface.

This point in time is what we know as First Paint (FP). It's the very first time the user has an opportunity to see something on the screen. Whether it will happen or not depends on the HTML the server sent. If there is something meaningful there, like a text or an image, then this point will also be when the First Contentful Paint (FCP) happened. If the HTML is just an empty div, then the FCP will happen later.

First Contentful Paint (FCP) is one of the most important performance metrics since it measures perceived initial load. Basically, it is the user's first impression of how fast your website is.

Until this moment, the users are just biting their nails while staring at the blank screen. According to Google, a good FCP number is below 1.8 seconds. After that, the users will start losing interest in what your website can offer and might start leaving.

However, FCP is not perfect. If the website starts its load with a spinner or some loading screen, the FCP metric will represent that. But it's highly unlikely that the user navigated to the website just to check out the fancy loading screen. Most of the time, they want to access the content.

For this, the browser needs to finish the work it started. It waits for the rest of the non-blocking JavaScript, executes it, applies changes that originated from it to the DOM on the screen, downloads images, and otherwise polishes the user experience.

Somewhere during this process is when the Largest Contentful Paint (LCP) time happens. Instead of the very first element, like FCP, it represents the main content area on the page - the largest text, image, or video visible in the viewport. According to Google, this number ideally should be below 2.5 seconds. More than that, and the users will think the website is slow.

All of those metrics are part of Google's Web Vitals - a set of metrics that represent user experience on a page. LCP is one of the three Core Web Vitals - three metrics that represent different parts of the user experience. LCP is responsible for the loading performance.

Those metrics can be measured by Lighthouse. Lighthouse is a Google performance tool that is integrated into the Chrome DevTools and can also be run via a shell script, web interface, or node module. You can use it in the form of a node module to run it inside your build and detect regressions before they hit production. Use the integrated DevTools version for local debugging and testing. And the web version to check out the performance of competitors.

Overview of the performance DevTools

All of the above is a very brief and simplified explanation of the process. But it's already a lot of abbreviations and theory to make a person's head spin. For me personally, reading something like this is of no use. I instantly forget everything unless I can see it in action and play around with it with my own hands.

For this particular topic, I find the easiest way to fully understand the concepts is to simulate different scenarios on a semi-real page and see how they change the outcome. So let's do exactly that before doing even more theory (and there is so much more!).

Setting up the project

You can do all of the simulations below on your own project if you wish - the results should be more or less the same. For a more controlled and simplified environment, however, I would recommend using a study project I prepared for this article. You can access it here: https://github.com/developerway/initial-load-performance

Start by installing all the dependencies:

npm install

Building the project:

npm run build

And starting the server:

npm run start

You should see a nice dashboard page at "http://localhost:3000".

Exploring the necessary DevTools

Open the website you want to analyze in Chrome and open Chrome DevTools. Find the "Performance" and "Lighthouse" panels there and move them closer together. We'll need both of them.

Also, before doing anything else in this article, make sure you have the "Disable cache" checkbox enabled. It should be in the Network panel at the very top.

This is so that we can emulate first-time visitors - people who've never been to our website before and don't have any resources cached by the browser yet.

Exploring the Lighthouse panel

Open the Lighthouse panel now. You should see a few settings there and the "Analyze page load" button.

"Navigation" mode is the one we're interested in for this section - it will run a detailed analysis of the page's initial load. The report will give you scores like this:

The local performance is perfect, no surprise there - everything always "works on my machine".

There will also be metrics like this:

The FCP and LCP values that we need for this article are right at the top.

Below, you'll see a list of suggestions that can help you improve your scores.

Every suggestion can be expanded, and you'll find more detailed information there, and sometimes links that explain that particular topic. Not all of them can be actioned, but it's an incredible tool to get started on performance and learn more about different things that can improve it. It's possible to spend hours just reading through those reports and the related links.

Lighthouse, however, only gives surface-level information and doesn't allow you to simulate different scenarios like a slow network or low CPU. It's just a great entry point and an awesome tool to track the performance changes over time. To dig deeper into what is happening, we need the "Performance" panel.

Exploring the Performance panel

When first loaded, the Performance panel should look something like this:

It shows the three Core Web Vitals metrics, one of which is our LCP, gives you the ability to simulate slow Network and CPU, and the ability to record performance details over time.

Find and check the "Screenshots" checkbox at the very top of the panel, then click the "Record and reload" button, and when the website reloads itself - stop the recording. This will be your detailed report on what is happening on the page during the initial load.

This report will have a few sections.

At the very top sits the general "timeline overview" section.

You'll be able to see here that something is happening on the website, but not much more. When you hover over it - the screenshot of what was happening will appear, and you'll be able to select and zoom in to a particular range to get a closer look.

Underneath, there is a Network section. When expanded, you'll see all the external resources that are being downloaded and at which exact time on the timeline. When hovering over a particular resource, you'll see detailed information on how much time was spent on which stage of the download. The resources with red corners will indicate the blocking resources.

If you're working on the study project, you'll see exactly the same picture, and this picture matches what we went through in the previous section to the letter:

At the beginning, there is the blue block - a request to get the HTML for the website
After it's finished loading, after a bit of a pause (to parse the HTML), two requests for more resources go out.
One of them (the yellow one) is for JavaScript - not blocking.
Another one (the purple one) is for CSS, and this one is blocking.

If you open your study project code now and peek into the dist folder, the source code matches this behavior:

There will be an index.html file and .css and .js files inside the assets folder
Inside the index.html file in the <head> section, there will be a <link> tag that points to the CSS file. As we know, CSS resources in the <head> are render-blocking, so that checks out.
Also, inside <head> there is a <script> tag that points to the JavaScript file inside the asset folder. It's neither deferred nor async, but it has type="module". Those are deferred automatically, so this also checks out - the JavaScript file in the panel is non-blocking.

Additional Exercise

If you have a project you're working on, record the initial load performance for it and look into the Network panel. You'll likely see many more resources downloaded.

How many render-blocking resources do you have? Are all of them necessary?
Do you know where the "entry" point for your project is and how blocking resources appear in the <head /> section? Try building the project with your variation of npm build and search for them. Hint:
- If you have a pure webpack-based project, look for webpack.config.js file. Paths to the HTML entry points should be inside.
- if you're on Vite, look into dist folder - same as with the study project
- if you're on the Next.js App router - take a peek into .next/server/app

Under the Network section, you can find the Frames and Timing sections.

Those are very cool. In the Timing section, you can see all the metrics we discussed before (FP, FCP, LCP), plus a few more we haven't yet. When hovering over the metrics, you can see the exact time it took. Clicking on them will update the "summary" tab at the very bottom, where you'll find information on what this metric is and a link to learn more. DevTools are all about educating people these days.

And finally, the Main section. This is what is happening in the main thread during the timeline recorded.

We can see stuff here like "Parse HTML" or "Layout" and how long it took. The yellow stuff is JavaScript-related, and they are a bit useless since we're using a production build with compressed JavaScript. But even in this state, it gives us a rough idea of how long the JavaScript execution takes compared to HTML parsing and drawing the Layout, for example.

It's especially useful for performance analysis when both Network and Main are open and zoomed in so they take the full screen.

From here, I can see that I have an incredibly fast server and fast and small bundles. None of the network tasks are a bottleneck; they don't take any significant time, and between them, the browser is just chilling and doing its own thing. So, if I wanted to speed up the initial load here, I need to look into why Parse HTML is so slow - it's the longest task on the graph.

Or, if we look at the absolute numbers - I shouldn't do anything here, performance-wise. The entire initial load takes less than 200ms and is way below Google's recommended threshold 🙂 But this is happening because I'm running this test locally (so no actual network costs), on a very fast laptop, and with a very basic server.

Time to simulate real life.

Exploring different network conditions

Very slow server

First of all, let's make the server more realistic. Right now, the very first "blue" step takes about 50ms, 40ms of which is just waiting.

In real life, the server will do stuff, check permissions, generate stuff, check permissions two times more (because it has lots of legacy code and that triple-checking got lost), and otherwise will be busy.

Navigate to the backend/index.ts file in your study project (https://github.com/developerway/initial-load-performance ). Find the commented out // await sleep(500), and uncomment it. This will give the server a 500ms delay before it returns the HTML - it seems reasonable enough for an old and complicated server.

Re-build the project (npm run build), re-start it (npm run start) and re-run the performance recording.

Nothing has changed on the timeline except for the initial blue line - it's now incredibly long compared to the rest of the stuff.

This situation highlights the importance of looking at the whole picture and identifying bottlenecks before doing any performance optimizations. The LCP value is ~650ms, out of which ~ 560ms is spent waiting for the initial HTML. The React portion of it is around 50ms. Even if I somehow manage to halve it and reduce it to 25ms, in the overall picture, it will be just 4%. And reducing it by half will require a lot of effort here. A much more effective strategy might be to focus on the server and figure out why it's so slow.

Emulating different bandwidth and latency

Not everyone lives in the world of a 1-gigabit connection. In Australia, for example, 50 megabits/second is one of the high-speed internet connections, and it will cost you around 90 Australian dollars a month. It's not 3G, of course, which plenty of people around the world are stuck with. But still, I cry every time I hear people in Europe bragging about their 1 gigabit/second or internet plans for 10 euros.

Anyway. Let's emulate this not-so-great Australian internet and see what will happen with the performance metrics. For that, clear the existing recording in the performance tab (the button near the reload and record). The panel with network settings should show up:

If it's not there in your version of Chrome, the same setting should be available in the Network tab.

Add a new profile in the "Network" dropdown with the following numbers:

Profile Name: "Average Internet Bandwidth"
Download: 50000 (50 Mbps)
Upload: 15000 (15 Mbps)
Latency: 40 (about average for general internet connection)

Now select that profile in the dropdown and re-run the performance recording again.

What do you see? For me, it looks like this.

LCP value barely changed - a slight increase from 640ms to 700ms. Nothing changed in the initial blue "server" part, which is explainable: it sends only the bare minimum HTML, so it shouldn't take long to download it.

But the relationship between the downloadable resources and the main thread changed drastically.

I can clearly see the impact of the render-blocking CSS file now. The Parse HTML task has finished already, but the browser is chilling and waiting for CSS - nothing can be painted until it's downloaded. Compare it with the previous picture, where the resources were downloaded almost instantly while the browser was parsing HTML.

After that, technically, the browser could've painted something - but there isn't anything, we're sending only an empty div in the HTML file. So the browser continues with the waiting until the javascript file is downloaded and can be executed.

This approximately 60ms gap of waiting is exactly the increase in the LCP that I'm seeing.

Downgrade the speed even more just to see how it progresses. Create a new Network Profile with 10mbps/1mbps for Download and Upload, keep the 40 latency, and name it "Low Internet bandwidth".

And run the test again.

The LCP value has increased to almost 500 ms now. The JavaScript download takes almost 300 ms. And the Parse HTML task and JavaScript executing tasks are shrinking in importance, relatively speaking.

Additional Exercise

If you have your own project, try to run this test on it.

How long does it take to download all the critical path resources?
How long does it take to download all the JavaScript files?
How much of a gap does this download cause after the Parse HTML task?
How large are the Parse HTML and JavaScript execution tasks in the main thread relative to the resource downloading?
How does it affect the LCP metric?

What's happening inside the resources bar is also quite interesting. Hover over the yellow JavaScript bar. You should see something like this there:

The most interesting part here is the "Request sent and waiting," which takes roughly 40 ms. Hover over the rest of the Network resources - all of them will have it. That's our Latency, the network delay, that we set to 40. Many things can influence the latency numbers. The type of the network connection is one of them. For example, an average 3G connection will have a bandwidth of 10/1 Mbps and latency between 100 and 300 ms.

To emulate that, create a new Network Profile, call it "Average 3G", copy the download/upload numbers from the "Low Internet bandwidth" profile, and set the latency to 300 ms.

Run the profiling again. All the Network resources should have "Request sent and waiting" increased to around 300 ms. This will push the LCP number even further: 1.2 seconds for me.

And now the fun part: what will happen if I revert the bandwidth to the ultra-high speeds but keep the low latency? Let's try this setting:

Download: 1000 Mbps
Upload: 100 Mbps
Latency: 300 ms

This can easily happen if your servers are somewhere in Norway, but the clients are rich Australians.

This is the result:

The LCP number is around 960ms. It's worse than the slowest internet speed we tried before! In this scenario, bundle size doesn't matter much, and the CSS size doesn't matter at all. Even if you halve both of them, the LCP metric will barely move. High latency trumps everything.

This brings me to the very first performance improvement everyone should implement if they haven't yet. It's called "make sure that the static resources are always served via a CDN."

The importance of CDN

CDN is basically a step 0 in anything frontend performance related, before even beginning to think about more fancy stuff like code splitting or Server Components.

The primary purpose of any CDN (Content Delivery Network) is to reduce latency and deliver content to the end user as quickly as possible. They implement multiple strategies for this. The two most important ones for this article are "distributed servers" and "caching."

A CDN provider will have several servers in different geographical locations. Those servers can store a copy of your static resources and send them to the user when the browser requests them. The CDN is basically a soft layer around your origin server that protects it from outside influence and minimizes its interaction with the outside world. It is kind of like an AI assistant for an introvert, which can handle typical conversations without the need to involve the real person.

In the example above, where we had servers in Norway and clients in Australia, we had this picture:

With the CDN in between, the picture will change. The CDN will have a server somewhere closer to the user, let's say also somewhere in Australia. At some point, the CDN will receive copies of the static resources from the origin server. After it does that, any user from Australia or anywhere close to it will get those copies rather than the originals from the server in Norway.

It achieves two important things. First, the load on the origin server is reduced since users don't have to access it directly anymore. And second, the users will get those resources much quicker now since they don't have to reach across oceans to download a few JavaScript files anymore.

And the LCP value in our simulation above drops from 960ms back to 640ms 🎉.

Repeat Visit Performance

Up until now, we have only been talking about first-time visit performance - performance for people who've never been to your website. But hopefully, the website is so good that most of those first-time visitors turn into regulars. Or at least they don't leave after the first load, navigate through a few pages, and maybe buy something. In this case, we usually expect the browsers to cache the static resources like CSS and JS - i.e., save a copy of them locally rather than always downloading them.

Let's take a look at how the performance graphs and numbers change in this scenario.

Open the study project again. In the dev tools, set the Network to the "Average 3G" we created earlier - with high latency and low bandwidth, just so we can see the difference right away. And make sure that the "disable network cache" checkbox is unchecked.

First, refresh the browser to make sure that we're eliminating the first-time visitor situation. And then refresh and measure the performance.

If you're using the study project, the end result should be slightly surprising because it will look like this:

The CSS and JavaScript files are still very prominent in the network tab, and I see ~300ms for both of them in "Request sent and waiting" - the latency setting we have in the "Average 3G" profile. As a result, the LCP is not as low as it could be, and I have a 300ms gap when the browser just waits for the blocking CSS.

What happened? Wasn't the browser supposed to cache those things?

Controlling Browser Cache with Cache-Control Headers

We need to use the Network panel now to understand what's going on. Open it and find the CSS file there. It should look something like this:

The most interesting things here are the "Status" column and "Size". In "Size" it's definitely not the size of the entire CSS file. It's too small. And in "Status," it's not our normal 200 "all's okay" status, but something different - 304 status.

Two questions here - why 304 instead of 200, and why was the request sent at all? Why didn't caching work?

First of all, the 304 response. It's a response that a well-configured server sends for conditional requests - where the response varies based on various rules. Requests like this quite often are used to control browser cache.

For example, when the server receives a request for a CSS file, it could check when the file was last modified. If this date is the same as in the cashed file on the browser side, it returns the 304 with an empty body (that's why it's just 223 B). This indicates to the browser that it's safe to just re-use the file it already has. There is no need to waste the bandwidth and re-download it again.

That's why we see the large "request sent and waiting" number in the performance picture - the browser asks the server to confirm whether the CSS file is still up-to-date. And that's why the "content downloading" there is 0.33ms - the server responded with "304 Not Modified" and the browser just re-used the file it downloaded before.

Additional exercise

In the study project, go to the dist/assets folder and rename the CSS file
Go to the dist/index.html file and update the path to the renamed CSS file
Refresh the already opened page with the opened Network tab You should see the CSS file appear with the new name, 200 status, and the proper size - it was downloaded again. It's known as "cache-busting" - a way to force the browser to re-download the resources it might have cached.
Refresh the page again - it's back to the 304 status and re-using the cached file.

Now, to the second question - why was this request sent at all?

This behavior is controlled by the Cache-Control header the server sets to the response. Click on the CSS file in the Network panel to see the details of the request/response. Find the "Cache-Control" value in the "Headers" tab in the "Response Headers" block:

Inside this header can be multiple directives in different combinations, separated by a comma. In our case, there are two:

max-age with a number - it controls for how long (in seconds) this particular response is going to be stored
must-revalidate - it directs the browser to always send a request to the server for a fresh version if the response is stale. The response will turn stale if it lives in the cache for longer than the max-age value.

So basically, what this header tells the browser is:

It's okay to store this response in your cache, but double-check with me after some time to make sure.
By the way, the time that you can keep that cache is exactly zero seconds. Good luck.

As a result, the browser always checks with the server and never uses the cache right away.

We can easily change that, though - all we need is to change that max-age number to something between 0 and 31536000 (one year, the maximum seconds allowed). To do that, in your study project, go to the backend/index.ts file, find where max-age=0 is set, and change it to 31536000 (one year). Refresh the page a few times, and you should see this for the CSS file in the Network tab:

Notice how the Status column is grayed out now, and for Size, we see "(memory cache)". The CSS file is now served from the browser's cache and it will be so for the rest of the year. Refresh the page a few times to see that it doesn't change.

Now, to the whole point of messing with the cache headers: let's measure the performance of the page again. Don't forget to set the "Average 3G" profile setting and keep the "disable cache" setting unchecked.

The result should be something like this:

The "Request sent and waiting" part collapsed to almost zero despite the high latency, the gap between "Parse HTML" and JavaScript evaluation almost disappeared, and we're back to the ~650ms for LCP value.

Additional exercise

Change the max-age value to 10 now (10 seconds)
Refresh the page with the "disable cache" checkbox checked to drop the cache.
Uncheck the checkbox and refresh the page again - it should be served from the memory cache this time.
Wait for 10 seconds, and refresh the page again. Because the max-age is only 10 seconds, the browser will double-check the resource, and the server will return the 304 again.
Refresh the page immediately - it should be served from memory again.

Cache-Control And Modern Bundlers

Does the above information mean that the cache is our performance silver bullet and that we should cache everything aggressively as much as possible? Absolutely not! Aside from everything else, the chance to create a combination of "not tech-savvy customers " and "need to explain over the phone how to clear browser cache" will cause panic attacks for the most seasoned developers.

There are a million ways to optimize the cache, a million combinations of the directives in the Cache-Control header in combination with other headers that may or may not influence how long the cache lives, which also may or may not depend on the implementation of the server. Probably a few books worth of information can be written just on this topic alone. If you want to become the Master of Cache, start with articles onhttps://web.dev/ and MDN resources, and then follow the breadcrumbs.

Unfortunately, nobody can tell you, "this is the five best cache strategies for everything." At best, the answer can be: "if you have this use case, in combination with this, this, and this, then this cache settings combination is a good choice, but be mindful of those hiccups". It all comes down to knowing your resources, your build system, how frequently the resources change, how safe it is to cache them, and what the consequences are if you do it wrong.

There is, however, one exception to this. An exception in a way that there is a clear "best practice": JavaScript and CSS files for websites built with modern tooling. Modern bundlers like Vite, Rollup, Webpack, etc., can create "immutable" JS and CSS files. They are not truly "immutable", of course. But those tools generate names for files with a hash string that depends on the content of the file. If the file's content changes, then the hash changes, and the name of the file changes. As a result, when the website is deployed, the browser will re-fetch a completely fresh copy of the file regardless of the cache settings. The cache is "busted," exactly like in the exercise before when we manually renamed the CSS file.

Take a look at the dist/assets folder in the study project, for example. Both js and CSS files have index-[hash] file names. Remember those names and run npm run build a few times. The names stay exactly the same since the content of those files didn't change.

Now go to src/App.tsx file and add something like a console.log('bla') somewhere. Run npm run build again, and check the generated files. You should see that the CSS file name stays exactly as it was before, but the JS file name changes. When this website is deployed, the next time a repeated user visits it, the browser will request a completely different JS file that never appeared in its cache before. The cache is busted.

Additional exercise

Find the equivalent of the dist folder for your project and run your build command.

What do the names of the files look like? Similar with hashes, or plain index.js, index.css, etc?
Do the names of the files change when you re-run the build command again?
How many file names change if you make a simple change somewhere in the code?

If this is how your build system is configured - you're in luck. You can safely configure your servers to set the maximum max-age header for generated assets. If you similarly version all your images - even better, you can include images to the list as well.

Depending on the website and its users and their behavior, this might give you a pretty nice performance boost for the initial load for free.

Do I really need to know all of this for my simple use case?

By this time, you might be thinking something like, "You're insane. I built a simple website over the weekend with Next.js and deployed it to Vercel/Netlify/HottestNewProvider in 2 minutes. Surely, those modern tools handle all of this for me?". And fair enough. I also thought that. But then I actually checked, and boy, was I surprised 😅

Two of my projects had max-age=0 and must-revalidate for CSS and JS files. Turned out it's the default in my CDN provider 🤷🏻‍♀️. They, of course, have a reason for this default. And luckily, it's easy to override, so no big deal. But still. Can't trust anyone or anything these days 😅.

What about your hosting/CDN provider? How sure are you about their cache headers configuration?

Hope that was a fun investigation, you learned something new and maybe even fixed an issue or two in your projects. I'm off working on the rest of the metrics now, while you're playing around with the study project (I hope). See you soon!

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter or Bluesky to get notified as soon as the next article comes out.

How React Compiler Performs on Real Code

Nadia Makarevich — Thu, 12 Dec 2024 07:17:00 +0000

The article follows the content and the structure of the talk I gave at "React Advanced" conference. If you prefer watching rather than reading, check it out: How React Compiler Performs On React Code

The problem of re-renders and memoization in React
React Compiler 🚀 to the rescue
React Compiler on simple examples
React Compiler on the real app
Initial load performance and the React Compiler
Interactions performance and React Compiler
Can React Compiler catch all re-renders?
Quick summary

In the last few years, one of the biggest sources of excitement and anticipation in the React community has been a tool known as React Compiler (previously React Forget). And for a good reason. The central premise of the Compiler is that it will improve the overall performance of our React apps. And as a nice consequence - that we'll never have to worry about re-renders, memoization, and useMemo and useCallback hooks.

But what's the problem with React's performance in the first place? And why do half of the devs desperately want to forget about memoization and those hooks? And how realistic is this promise?

This is what the article tries to answer. It summarises the problem the Compiler is trying to solve, how it is solved without the Compiler, and how the Compiler works on real code - I run it on an app that I've been working on for a while and measured the result of that.

The problem of re-renders and memoization in React

So, what exactly is the problem here?

Most of the React apps out there are written to show some interactive UI (User Interface) to the user. When the user interacts with the UI, we usually want to update the page with some new information derived from that interaction. To do this in React, we trigger what is known as re-render.

Re-renders in React normally are cascading. Every time a re-render of a component is triggered, it triggers a re-render of every nested component inside, which triggers the re-render of every component inside, and so on and so forth, until the end of the React components tree is reached.

Normally, this is not something to worry about - React is pretty fast these days. However, if those downstream re-renders affect some heavy components or components that just re-render too much, this might cause performance problems. The app will become slow.

One way to fix this slowness is to stop the chain of re-renders from happening.

We have multiple techniques to do that - moving state down, passing components as props, extracting state into Context-like solution to bypass props drilling, to name a few. And memoization, of course.

Memoization starts with React.memo - a higher-order component was given to us by the React team. To make it work, all we need to do is wrap our original component with it and render the "memoized" component in its place.

// memoize a slow component here
const VerySlowComponentMemo = React.memo(VerySlowComponent);

const Parent = () =&gt; {
  // trigger re-render somewhere here

  // render the memoized component in place of the original
  return ;
};

Now, when React reaches this component in the tree, it will stop and check whether its props have changed. If none of the props change, the re-renders will be stopped. However, if even one single prop has changed, React will continue with re-renders as if no memoization happened!

That means that for the memo to work properly, we need to make sure that all props stay exactly the same between re-renders.

For primitive values, like strings and booleans, it's easy: we don't need to do anything other than just not changing those values.

const VerySlowComponentMemo = React.memo(VerySlowComponent);

const Parent = () =&gt; {
  // trigger re-render somewhere here

  // "data" string between re-renders stays the same
  // so memoization will work as expected
  return ;
};

Non-primitive values, like objects, arrays, and functions, however, need some help.

React uses referential equality to check for anything between re-renders. And if we declare those non-primitives inside the component, they will be re-created on every re-render, reference to them will change, and memoization won't work.

const VerySlowComponentMemo = React.memo(VerySlowComponent);

const Parent = () =&gt; {
  // trigger re-render somewhere here

  // "data" object is re-created with every re-render
  // memoization is broken here
  return ;
};

To fix this, we have two hooks: useMemo and useCallback. Both of those will preserve the reference between re-renders. useMemo is typically used with objects and arrays, and useCallback with functions. Wrapping props into those hooks is what we usually know as "memoizing props".

const Parent = () =&gt; {
  // reference to { id:"123" } object is now preserved
  const data = useMemo(() =&gt; ({ id: "123" }), []);
  // reference to the function is now preserved
  const onClick = useCallback(() =&gt; {}, []);

  // props here don't change between re-renders anymore
  // memoization will work correctly
  return (

  );
};

Now, when React encounters the VerySlowComponentMemo component in the render tree, it will check whether its props have changed, will see that none of them have, and will skip its re-renders. The app is not slow anymore.

This is a very much simplified explanation, but it's quite complex already. To make the situation even worse, if we pass those memoized props through a chain of components, it becomes even more complicated - any change to them would require tracing those chains back and forth to make sure the reference is not lost in between.

As a result, it's easier just not to do it at all or memoize everything everywhere just in case. Which, in turn, turns our beautiful code into an incomprehensible and unreadable mess of useMemo and useCallback.

Solving this situation is the React Compiler's main promise.

React Compiler 🚀 to the rescue

React Compiler is a Babel plugin developed by the React core team, with the Beta version released in October 2024.

During build time, it tries to convert the "normal" React code into the code where components, their props, and the dependencies of hooks are memoized by default. The end result is the "normal" React code that behaves as if everything is wrapped in memo, useMemo, and useCallback.

Almost! In reality, it does much more complicated conversions and tries to adjust to the code as efficiently as possible. For example, something like this:

function Parent() {

  const data = { id: "123" };
  const onClick = () => {

  };

  return <Component onClick={onClick} data={data} />
}

Will be transformed into this:

function Parent() {
  const $ = _c(1);
  let t0;
  if ($[0] === Symbol.for("react.memo_cache_sentinel")) {
    const data = {
      id: "123",
    };
    const onClick = _temp;
    t0 = <Component onClick={onClick} data={data} />;
    $[0] = t0;
  } else {
    t0 = $[0];
  }
  return t0;
}
function _temp() {}

Notice how onClick is cached as a _temp variable, but data is just moved inside the if statement. You can play around with it some more in the Compiler Playground.

The mechanics of how it works are fascinating, so if you want to know more, there are a few videos by the React core team available, such as the Deep dive into the Compiler talk.

For the purpose of this article, however, I am more interested in whether our expectations from the Compiler match the reality and whether it's ready for use by the broader public like me.

The main questions that immediately come to mind for almost everyone when they hear about "the Compiler will memoize everything":

What about initial load performance? One of the big arguments against "memoizing everything by default" has always been that it can negatively affect it since React has to do much more stuff in advance when everything is memoized
Will it have a positive performance impact at all? How much of a problem re-renders really are?
Can it really catch all re-renders? JavaScript is notorious for being fluid and ambiguous. Is the Compiler smart enough to really catch everything? Is it true that we'll never have to think about memoization and rerenders ever again?

To answer those questions, I run the Compiler on a few synthetic examples, just to make sure it actually works, and then run it on a few pages of an app I'm working on.

React Compiler on simple examples

The first example is this.

const SimpleCase = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>toggle</button>
      {isOpen && <Dialog />}
      <VerySlowComponent />
    </div>
  );
};

I have a component with a dialog, a state for this dialog, a button that can open it, and a VerySlowComponent somewhere underneath. Let's say it takes 500ms to rerender it.

Normal React behavior would be to re-render everything when the state changes. As a result, the dialog pops up with a delay because of the slow component. If I wanted to fix it with memoization, I'd have to wrap the slow component into memo:

const VerySlowComponentMemo = React.memo(VerySlowComponent);

const SimpleCase = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>toggle</button>
      {isOpen && <Dialog />}
      <VerySlowComponentMemo />
    </div>
  );
};

Let's instead enable the Compiler for the code. First of all, I see this in the React Dev Tools:

That means that the Button and VerySlowComponent are memoized by the Compiler. And if I add a console.log inside the VerySlowComponent, it's not triggered when I change state. That means that the memoization indeed works, works correctly, and the performance problem here is fixed. When I trigger the dialog, it pops up without a delay.

In the second example, I added more props to the slow component:

const SimpleCase = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>toggle</button>
      {isOpen && <Dialog />}
      // add "data" and "onClick" props
      <VerySlowComponent data={{ id: "123" }} onClick={() => {}} />
    </div>
  );
};

Manually, I'd need to memoize using all three tools: memo, useMemo, and useCallback.

const SimpleCase = () => {
  const [isOpen, setIsOpen] = useState(false);
  const data = useMemo(() => ({ id: "123" }), []);
  const onClick = useCallback(() => {}, []);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>toggle</button>
      {isOpen && <Dialog />}
      <VerySlowComponentMemo data={data} onClick={onClick} />
    </div>
  );
};

The Compiler performed flawlessly here again, and the result was the same as in the first example: everything is memoized correctly, and the Dialog pops up without a delay.

In the third example, I passed another component as children to the slow component like this:

const SimpleCase = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>toggle</button>
      {isOpen && <Dialog />}

      <!-- Acceps Child now -->
      <VerySlowComponent>
        <Child />
      </VerySlowComponent>
    </div>
  );
};

Do you know, off the top of your head, how to memoize that thing correctly? Most people would think it's this:

const VerySlowComponentMemo = React.memo(VerySlowComponent);
const ChildMemo = React.memo(Child);

const SimpleCase = () => {

  return (
    <div>
      ...
      <VerySlowComponentMemo>
        <ChildMemo />
      </VerySlowComponentMemo>
    </div>
  );
};

Which is, unfortunately, incorrect. The tree-like syntax here is nothing more than syntax sugar for children prop. The code example above can easily be re-written to be this:

const VerySlowComponentMemo = React.memo(VerySlowComponent);
const ChildMemo = React.memo(Child);

const SimpleCase = () => {

  return (
    <div>
      ...
      <VerySlowComponentMemo children={<ChildMemo />} />
    </div>
  );
};

Also, <ChildMemo /> here is again nothing more than syntax sugar for an Element, which is a result of React.createElement function call, which is an object with type property pointing to the ChildMemo function:

const VerySlowComponentMemo = React.memo(VerySlowComponent);
const ChildMemo = React.memo(Child);

const SimpleCase = () => {

  return (
    <div>
      ...
      <VerySlowComponentMemo children={{ type: ChildMemo }} />
    </div>
  );
};

What we have here, unfortunately, is a non-memoized object as a prop to the memoized component. Memoization doesn't work, and VerySlowComponentMemo will re-render with every state change.

The correct way to memoize this example is to do it as any other object:

const VerySlowComponentMemo = React.memo(VerySlowComponent);
const ChildMemo = React.memo(Child);

const SimpleCase1 = () => {
  const children = useMemo(() => <ChildMemo />, []);

  return (
    <div>
      ...
      <VerySlowComponentMemo>
        {children}
      </VerySlowComponentMemo>
    </div>
  );
};

The result of enabling the Compiler on the non-memoized third example was exactly the same as before: the Compiler managed to memoize it correctly, the performance problem was fixed.

That is three out of three for the Compiler so far. 🏆🏆🏆

But small examples like that are "easy." To test the Compiler properly, I run it on a real app I've been working on for a while.

React Compiler on the real app

The app is completely new, fully typescriptified, has no legacy code, only hooks, and everything is the latest best practices (more or less). It has a landing page, a few internal pages, and is around 15k lines of code. Not the largest app ever, but good enough for a proper test, I'd say.

Before turning on the compiler, I ran the health check and the eslint rules provided by the React team. That's the health check results:

Successfully compiled 361 out of 363 components.

Found no usage of incompatible libraries.

And I had zero eslint rules violations.

I used Lighthouse to measure initial load and interaction performance. Everything is measured on production build in the "mobile" mode with the CPU slowed down 4 times. And I ran all the tests 5 times and extracted the average.

Time to answer the questions.

Initial load performance and the React Compiler

The very first page I measured was the "landing" page of the app. Those are the stats before enabling the Compiler:

Enabling the Compiler and making sure it works:

And measuring the result:

The first picture is before, the second is after. As you can see, the results are pretty much identical.

To be sure, I ran it on a few more pages, and the results were more or less the same. Some numbers would increase a little, some would even decrease. Nothing drastic.

I think I can add another win to the Compiler (🏆🏆🏆🏆) and answer the first question I was investigating: the Compiler seems to have minimal to no impact on the initial load. So that's good. It doesn't make things worse despite memoizing everything.

Interactions performance and React Compiler

Measuring the first page

To measure the interaction performance, I started with a "component" page. On this page, I'm showing a preview of React components for the UI components library I'm working on. The preview can be anything from a button to an entire page. I measured the preview of a "Settings" page.

The preview page has "light" and "dark" mode toggle. As you can see below, toggling the mode causes the preview to re-render - the green lines indicate that.

The performance of this interaction before and after the Compiler looks like this:

Total blocking time dropped from 280ms to literally zero with the Compiler enabled!

This is very impressive. But it also made me curious: how exactly this happened? What did I do so wrong in the code?

The code for this page looks like this:

export default function Preview() {
  const renderCode = useRenderCode();
  const darkMode = useDarkMode();

  return (
    <div
      className={merge(
        darkMode === "dark" ? "dark bg-buGray900" : "bg-buGray25",
      )}
    >
      <LiveProvider
        code={renderCode.trim()}
        language="tsx"
      >
        <LivePreview />
      </LiveProvider>
    </div>
  );
}

The LiveProvider block is the thing that renders the entire "Settings" component passed to it as a string. I literally have here one of the simple examples I explored at the beginning - a Very Slow Component (LiveProvider) with a few props.

The Compiler managed to pick this up, which is very cool. But also, it feels a bit like cheating 😅 A more common scenario would be to have a bunch of small to medium-sized components everywhere. So, I measured the next page, which feels a bit closer to it.

Measuring second page

On the next page, I have a bunch of components in the header, some footer, and a list of Cards in between. In the header, there are a few "quick filters": Button, Input Field, Checkbox. When I select the Button, I see the list of all the Cards that have Button inside. When I enable the Checkbox - the list is updated with additional cards that also have a Checkbox inside.

Without memoization, the entire page, including the very long list of cards, re-renders.

The performance of adding Checkbox cards to the already existing list before and after the Compiler looks like this.

The blocking number dropped from 130 ms to 90 ms. Still pretty good and much more realistic! However, if all re-renders on that page had been eliminated, I would've expected the numbers to drop much more. Adding just a few cards to an already existing list should've been almost instantaneous.

I checked the re-renders situation here, and unfortunately - yes. While most of the re-renders have been eliminated, the cards themselves, which happen to be the heaviest on the page, still re-render.

Checking the code again - and it's a mystery. Because the code is the most standard code you'll see in React. Just map over an array of data and render GalleryCard item inside.

{data?.data?.map((example) => {
    return (
      <GalleryCard
        href={`/examples/code-examples/${example.key}`}
        key={example.key}
        title={example.name}
        preview={example.previewUrl}
      />
    );
  })}

The very first thing that I do when debugging Compiler issues is to re-implement memoization with the classic tools. In this case, all I need to do is to wrap the card in React.memo, and if the code is good, the existing cards should stop re-rendering and that would mean that the Compiler bailed on this component for some reason.

// somewhere before
const GalleryCardMemo = React.memo(GalleryCardMemo);

// somewhere in render function
{data?.data?.map((example) => {
  return (
    <GalleryCardMemo
      href={`/examples/code-examples/${example.key}`}
      key={example.key}
      title={example.name}
      preview={example.previewUrl}
    />
  );
})}

Which doesn't happen.

That means that the Compiler is not at fault - something is deeply wrong with the code itself.

As we already know, if even a single prop changes on a memoized component, then the memoization won't work, and re-render will happen. So, something must be wrong with the props. Upon closer examination, all of them turned out to be primitive strings except for this one: example.previewUrl. This turned out to be an object:

{
  light: "/public/light/...",
  dark: "/public/dark/...",
};

So, the object changes its reference between re-renders, then. But how? it's coming from a data variable, which in turn comes from querying a REST endpoint with the React Query library:

const { data } = useQuery({
  queryKey: ["examples", elements.join(",")],
  queryFn: async () => {
    const json = await fetch(`/examples?elements=${elements.join(",")}`);
    const data = await json.json();
  return data;
},
});

React Query caches the data that is returned from queryFn based on the key provided in the queryKey. Looks like, in my case, I'm changing the key based on the selected element by joining the elements array. So if only the Button is selected, the key will be button, if the Checkbox is added to the list, the key turns into button,checkbox.

So my theory here is that React Query thinks of those two keys and the data returned for them as completely different data arrays. This makes a lot of sense to me - I haven't indicated to it in any way that those arrays are the same and can be just updated.

So what happens, I suspect, is that when the key changes from button to button,checkbox the query library fetches the new data and returns it as a completely new array with all the objects inside having completely new references. As a result, the memoized GalleryCard component receives a new reference for one of its non-primitive props, memoization for it doesn't work, and it still re-renders, even though the data is technically the same.

It's very easy to verify this: I just need to turn that object into primitive props to get rid of the changing reference.

{data?.data?.map((example) => {
  return (
    <GalleryCardMemo
      href={`/examples/code-examples/${example.key}`}
      key={example.key}
      title={example.name}
      // pass primitives values instead of the entire object
      previewLight={example.previewUrl.light}
      previewDark={example.previewUrl.dark}
    />
  );
})}

And indeed, all re-renders stopped completely after I've done it!

Final step: measure it to see how much of an impact my change actually had.

Boom! Blocking time dropped to zero, Interaction to Next Paint more than halved. It's a 🎤 drop situation, I feel. The Compiler improved the performance a little bit, but I did it much better ✌🏼 💪🏼

I think this can answer the second most common question: can the Compiler have an impact on interaction performance? The answer: it can, it's noticeable but varies from page to page, and humans are still better at it if they really try.

Can React Compiler catch all re-renders?

Time to answer the final question. Is the Compiler smart enough to really catch everything? We already seen that the answer here is probably a no.

But to test it a bit more, I collected a list of the most noticeable re-renders in my app and checked how many re-renders were still present after I enabled the Compiler.

I identified 9 cases of noticeable re-renders, situations like "the entire drawer re-renders when tabs change" and so on. This is the end result. Out of 9 cases:

I had two where all re-renders were completely 100% fixed
two where not a single one of them was fixed
and the rest were somewhere in between, like in the investigation above.

The cases where nothing was fixed were the Compiler bailed out from the component because of this line, by the way:

const filteredData = fuse.search(search);

Just this line alone. I never even used the filteredData variable anywhere. fuse here is an external fuzzy search library. So, the most likely reason for this behavior is that the library is doing something incompatible with the compiler, and this is out of my control.

So the answer to whether the Compiler can catch absolutely every re-render is clear here. It's a definite no. There will always be some external dependency that is just plain incompatible with the Compiler itself or with the memoization rules.

Or there will be some weird legacy code that the Compiler doesn't know how to process.

Or the code that I had, which is not exactly wrong per se but just not fine-tuned for memorization.

Quick summary

Let's quickly summarise the results of the investigation and the outcome.

Initial load performance - I saw no negative impact.
Interactions performance - they improved, some of them a lot, some of them a little.
Can it catch all re-renders - no, and it never will.

Does it mean that the answer to the question "Can we forget about memoization soon?" is a "no"? Not necessarily! It depends.

If the performance of your app is not the most important thing in the world, or if it's "okay-ish, could be better, but I couldn't be bothered", enabling the Compiler will likely make it slightly better or even good enough at a low cost. The definition of "good enough" will be up to you. But I suspect that for most people, turning on the Compiler and forgetting about memoization will be enough.

However! If "good enough" is not so good for you, and you need to squeeze every millisecond out of your app, welcome back to the manual memoization.

For you, the answer will be no - you can't forget them. Sorry. You'd have to know everything that we need to know now, plus on top of that - what the Compiler does and how. So your job will become slightly harder.

But I think there will be very few of you who would actually need to know all of this.

And if you want to be one of those people, I wrote lots of articles on the topic, released a bunch of YouTube videos, and even wrote a book, half of which is dedicated to re-renders and how to get rid of them. Check them out 😉

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter or Bluesky to get notified as soon as the next article comes out.

Existential React questions and a perfect Modal Dialog

Nadia Makarevich — Thu, 05 Dec 2024 01:34:07 +0000

What do you think is the most complicated thing in React? Re-renders? Context? Portals? Concurrency?

Nope.

The hardest part of React is everything non-React around it. The answer to the question "How do those things listed above work?" is straightforward: it's just a matter of following the algorithm and taking notes. The result will be definitive and always the same (if you trace it down correctly). It's just science and facts.

But what about "What makes a component good?" or "What is the right way to implement… (something)?" or even "Should I use a library or build my own solution?" The only factually correct answer here is "It depends." It happens to be the least helpful one.

I wanted to find something better than this for the new article. But since there can't be simple answers and universal solutions for those types of questions, the article turned out to be more of a walk-through of my thought process rather than "this is the answer, do it always." Hope it's still useful.

So, what it takes to move a feature from an idea to a production-ready solution? Let's try to implement a simple Modal Dialog and see. What can possibly be complicated about that one? 😉

Step 1: Start with the simplest solution

Let's start with what is sometimes known as a "spike" - the simplest possible implementation that can help explore potential solutions and gather further requirements. I know that I'm implementing a modal dialog. Let's assume I have a pretty design like this:

A dialog is basically an element on the screen that appears when something like a button is clicked. So that's exactly where I'll start.

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

State, a button that listens for clicks, and a future dialog that is shown when the state is true. Dialog is also supposed to have a "close" action:

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

It also has a "backdrop" - a clickable semi-transparent div that overlays the content and triggers the modal's disappearance when clicked.

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

All together:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

I also usually add decent styles early on. Seeing the feature I'm implementing appear on the screen with the same look as it is supposed to helps me think. Plus, it can inform the layout of the feature, which is exactly what will happen with this dialog.

Let's quickly add CSS for the backdrop - it's nothing special, just a semi-transparent background on a div with position: fixed that takes the entire screen:

.backdrop {
  background: rgba(0, 0, 0, 0.3);
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

The dialog is slightly more interesting since it needs to be positioned in the middle of the screen. There are 1001 ways to achieve that in CSS, of course, but my favorite and probably the simplest one is this:

.dialog {
  position: fixed;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

We use a "fixed" position to escape from the layout constraints, add 50% left and top to move the div in the middle-ish, and transform it back by 50%. The left and top will be calculated relative to the screen, and the transform will be relative to the width/height of the div itself, so as a result, it will appear right in the middle regardless of its width or width of the screen.

The last bit of CSS in this step is to properly style the dialog itself and the "close" button. Not going to copy-paste it here, the actual styles are not that important, just take a look at the example:

Step 2: stop, ask questions and think

Now that I have a rough implementation of the feature, it's time to make it "real." To do that, we need to understand in detail what exactly we're trying to solve here and for whom. Technically speaking, we should understand that before coding anything, so quite often, this step should be Step 1.

Is this dialog part of a prototype that needs to be implemented as quickly as possible, shown to the investors once, and never used again? Or maybe it's part of a generic library that you're going to publish on npm and open source? Or maybe it's part of the design systems that your 5,000-person organization will use? Or is it part of the internal tooling for your small 3-person team and nothing else? Or maybe you work for something like TikTok, and this dialog will be part of the web app available only on mobile? Or maybe you work for an agency that writes apps for the government only?

Answering those questions sets the direction of what to do next when it comes to coding.

If it's just a prototype to be used once, it might be good enough already.

If it's going to be open-sourced as part of a library, it needs to have a very good general-purpose API that any developer in the world can use and understand, lots of tests, and good documentation.

The dialog that is part of the design systems of a 5,000-person org needs to adhere to the organization's design guidelines and might be restricted in what external dependencies are brought into the repo. So, you might need to implement many things from scratch rather than doing npm install new-fancy-tool.

The dialog of an agency that builds for the government probably needs to be the most accessible and regulations-compliant dialog in the universe. Otherwise, the agency might lose the government contracts and go bankrupt.

And so on and so on.

For the purpose of this article, let's assume that the dialog is part of a fresh, currently in-progress redesign of an existing large commercial website with thousands of users from all over the world daily. The redesign is so in progress that the only design with the dialog I got is this:

The rest will come later, the designers are swamped. Also, I'm part of the permanent team that does the re-design and maintains the website going forward, not an external contractor hired for a single project.

In this case, having only this picture and knowing about our company's goal gives me enough information to make reasonable assumptions and implement 90% of the dialog. The rest of the 10% can be fine-tuned later.

Those are the assumptions I can make based on the information above:

The existing website has thousands of users daily from all over the world, so I need to ensure the dialog, at the very least, works on both large and mobile screens, as well as different browsers. Ideally, I need to check existing analytics to be absolutely sure, but it's a pretty safe bet.
More than one developer is writing code for this, and the code is here to stay. The website is large and already has thousands of users; it's not a quick prototype for the investors. So, I need to make sure that the code is readable, the API makes sense, it is usable and maintainable, and it doesn't have obvious foot guns.
The company cares about its image and the quality of its website - otherwise, why would they do a redesign at all? (Let's assume positive intent here 😅). That means that a certain level of quality is expected, and I need to think ahead and anticipate common scenarios and edge cases, even if they are not part of the current design yet.
Many users likely mean that not all of them exclusively use the mouse to interact with the website. The dialog must also be available via keyboard interactions and maybe even assistive technology like screen readers.
A large existing codebase (it's a re-design, remember!) means that there are likely restrictions on the external dependencies I can bring for this feature. Any external dependency comes at a cost, especially in large and old codebases. For the purpose of the article, let's assume that I can use an external library, but I would need to have a good rationale for this.
Finally, more designs are coming, so I need to anticipate which way it can go from the design and user point of view and make sure the code can handle it early on.

Step 3: solidify the Modal Dialog API

Now that I know the requirements and have reasonable guesses, I can make the actual dialog component. First of all, from this code:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

I absolutely need to extract the dialog portion into a reusable component - there will be plenty of dialog-based features to implement.

const ModalDialog = ({ onClose }) => {
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className="dialog">
        <button className="close-button" onClick={onClose}>
          Close
        </button>
      </div>
    </>
  );
};

The dialog will have an onClose prop - it will notify the parent component when the "close" button or the backdrop is clicked. The parent component will then still have the state and render the dialog like this:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <ModalDialog onClose={() => setIsOpen(false)} />
      ) : null}
    </>
  );
}

Now, let's look at the design again and think about dialogs some more:

There clearly will be some "footer" part of the dialog with action buttons. Most likely there will be plenty of variations of those buttons - one, two, three, aligned to the left, right, with space in between, etc. Also, this dialog doesn't have a header, but it's very, very likely that it might have - dialogs with some header are a pretty common pattern. There will absolutely be a content area here with completely random content - from just confirmation text to forms to interactive experiences to very long "terms and conditions" scrollable texts that no one reads.

Finally, the size. The dialog in the design is tiny, just a confirmation dialog. Large forms or long texts won't fit there. So, considering the information we gathered in Step 2, it's pretty safe to assume that the size of the dialog will need to be changed. At this moment, considering that the designers likely have design guidelines, we can assume that we'll have three variations of the dialog: "small," "medium," and "large."

All of this means we need to have props on the ModalDialog: footer and header will be just regular props that accept ReactNode, size will be just a union of strings, and the content area, as the main part, will go into children:

type ModalDialogProps = {
  onClose: () => void;
  footer?: ReactNode;
  header?: ReactNode;
  children: ReactNode;
  size: 'small' | 'medium' | 'large';
};

const ModalDialog = ({
  onClose,
  size,
  header,
  footer,
  children,
}: ModalDialogProps) => {
  // control the size here
  const className = `dialog ${size}`;
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className={className}>
        <button className="close-button" onClick={onClose}>
          Close
        </button>
        {header}
        {children}
        {footer}
      </div>
    </>
  );
};

We'll control the size of the dialog with an additional className coming from the props. In real life, it will highly depend on the styling solution that is used in the repo though.

However, in this variant, the dialog is just too flexible - pretty much anything can go everywhere. In the footer, for example, most of the time, we can expect just a button or two, nothing more. And those buttons would have to be consistently arranged everywhere throughout the website. We need to have a wrapper that aligns them:

<div className="footer">{footer}</div>

Same with the content - at the very least, it would need some padding around it and the scrolling ability. And the header might need some styles for the text. So the layout turns into this:

const ModalDialog = ({
  onClose,
  size,
  header,
  footer,
  children,
}) => {
  const className = `dialog ${size}`;
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className={className}>
        <button className="close-button" onClick={onClose}>
          Close
        </button>
        <div className="header">{header}</div>
        <div className="content">{children}</div>
        <div className="footer">{footer}</div>
      </div>
    </>
  );
};

But unfortunately, we can't guarantee that. It's highly probable that, at some point, someone would want to have something more in the footer other than buttons. Or some of the dialogs would need to have a header on a sold background. Or sometimes, the content won't need paddings.

What I'm leading to here is that we'd need to be able to style the header/content/footer part someday. And probably sooner than expected.

We could, of course, just pass that configuration with props and have something like headerClassName, contentClassName, and footerClassName props. And for some cases, it could be okay, actually. But for something like the nice dialog for the nice redesign, we could do better.

A really neat way to solve this problem is to extract our header/content/footer into components of their own, like this:

const DialogFooter = ({ children }) => {
  return <div className="footer">{children}</div>;
}
...
// same for content and header

and revert the ModalDialog code to the code without the wrappers:

const ModalDialog = ({
  onClose,
  size,
  header,
  footer,
  children,
}) => {
  const className = `dialog ${size}`;
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className={className}>
        <button className="close-button" onClick={onClose}>
          Close
        </button>
        {header}
        {children}
        {footer}
      </div>
    </>
  );
};

That way, in the parent app, if I want to have the default design for the dialog parts, I'd use those tiny components:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <ModalDialog
          onClose={() => setIsOpen(false)}
          header={<DialogHeader>Header</DialogHeader>}
          footer={<DialogFooter>Footer</DialogFooter>}
          size="medium"
        >
          <DialogContent>Content</DialogContent>
        </ModalDialog>
      ) : null}
    </>
  );
}

And if I wanted to have something completely custom, I would implement a new component with its own custom styles without messing with the ModalDialog itself:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      ...
      <ModalDialog
        onClose={() => setIsOpen(false)}
        header={<CustomHeader>Header</CustomHeader>}
        footer={<CustomFooter>Footer</CustomFooter>}
        size="medium"
      >
        <SomethingElse>Content</SomethingElse>
      </ModalDialog>
      ...
    </>
  );
}

For that matter, I don't even need the header and footer prop anymore. I can just pass the DialogHeader and DialogFooter to the children, simplify the ModalDialog even more, and have an even nicer API with the same level of flexibility while having consistent design everywhere.

The parent component will then look like this:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <ModalDialog
          onClose={() => setIsOpen(false)}
          size="medium"
        >
          <DialogHeader>Header</DialogHeader>
          <DialogContent>Content</DialogContent>
          <DialogFooter>Footer</DialogFooter>
        </ModalDialog>
      ) : null}
    </>
  );
}

And the dialog's API will look like this:

export const ModalDialog = ({
  onClose,
  size,
  children,
}) => {
  const className = `dialog ${size}`;
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className={className}>
        <button className="close" onClick={onClose}>
          Close
        </button>
        {children}
      </div>
    </>
  );
};

export const DialogFooter = ({ children }) => {
  return <div className="footer">{children}</div>;
};

export const DialogHeader = ({ children }) => {
  return <div className="header">{children}</div>;
};

export const DialogContent = ({ children }) => {
  return <div className="content">{children}</div>;
};

I'm pretty happy with it so far. It's flexible enough to extend in any way the design might require, but it's also clear and sensible enough to implement a consistent UI across the entire app easily.

Here's the live example to play around with:

Step 4: performance and re-renders

Now that the Modal's API is in decent enough shape, it's time to address the obvious foot gun I implemented. If you've read enough of my articles, you probably have been screaming loudly, "what r u doing??? Re-renders!!" for the last ten minutes 😅 And of course, you're right:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <ModalDialog
          onClose={() => setIsOpen(false)}
          size="medium"
        >
          <DialogHeader>Header</DialogHeader>
          <DialogContent>Content</DialogContent>
          <DialogFooter>Footer</DialogFooter>
        </ModalDialog>
      ) : null}
    </>
  );
}

The Page component here has state. Every time the modal is open or closed, the state will change, and it will cause a re-render of the entire component and everything inside. While yes, "premature optimization is the root of all evil," and yes, don't optimize performance before actually measuring it, in this case, we can safely ignore the conventional wisdom.

For two reasons. First, I know for a fact that there will be lots of modals scattered throughout the app. It's not a one-time hidden feature that no one is going to use. So, the chances that someone will put a state somewhere where it shouldn't be with an API like this are quite high. And second, it doesn't take much time and effort to prevent the re-renders problem from ever occurring in the first place. Just 1 minute of effort, and we won't need to think about the performance here at all.

All we need to do is to encapsulate state and introduce the idea of an "uncontrolled component":

export const ModalDialog = (props) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      {isOpen ? (
        <BaseModalDialog
          {...props}
          onClose={() => setIsOpen(false)}
        />
      ) : null}
    </>
  );
};

Where the BaseModalDialog is exactly the same dialog we had before, I just renamed it.

And then pass a component that is supposed to trigger the dialog as a trigger prop:

export const ModalDialog = ({
  // add the prop here
  trigger,
  ...props
}) => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      <!-- render trigger here -->
      <span onClick={() => setIsOpen(!isOpen)}>{trigger}</span>
      {isOpen ? (
        <BaseModalDialog {...props} onClose={() => setIsOpen(false)} />
      ) : null}
    </>
  );
};

The Page component then will look like this:

export default function Page() {
  return (
    <>
      <-- other stuff relevant to the page -->
      <ModalDialog
        trigger={<button>Click me</button>}
        size="medium"
      >
        <DialogHeader>Header</DialogHeader>
        <DialogContent>Content</DialogContent>
        <DialogFooter>Footer</DialogFooter>
      </ModalDialog>
    </>
  );
}

No more state inside Page, no more potentially dangerous re-renders.

An API like this should cover 95% of the use cases since, most of the time, a user would need to click on something for the dialog to appear. In rare situations when a dialog needs to appear independently, for example, on a shortcut or as part of the onboarding, I can still use the BaseModalDialog and deal with the state manually.

Step 5: dealing with edge cases and accessibility

The API of the ModalDialog component is pretty solid from the React perspective, but the job is nowhere near done. Considering the must-haves I gathered in Step 2, I still need to fix a few more issues.

Issue 1: I'm wrapping the trigger into an additional span - in certain cases, that might break the layout of a page. I need to get rid of the wrapper somehow.

Issue 2: If I render the dialog inside an element that creates a new Stacking Context, the modal will appear underneath some elements. I need to render it inside a Portal, not directly inside the layout like I'm doing now.

Issue 3: Keyboard access is pretty bad at the moment. When a properly implemented modal dialog opens, the focus should jump inside. When it's closed - the focus should return to the element that triggered the dialog. When the dialog is open, the focus should be "trapped" inside, and the elements outside should not be focusable. Pressing the ESC button should close the dialog. None of this is implemented at the moment.

Issues 1 and 2 are slightly annoying but can be solved relatively fast. Issue 3, however, is a massive pain to do manually. Plus, surely it's a solved problem - every dialog everywhere would need this functionality.

The combination of "massive pain to do by myself" + "looks like surely a solved problem" is where I would look for an existing library.

Considering all the pre-work I already did, choosing the right one is easy now.

I could go for any existing UI component libraries like Ant Design or Material UI and use a dialog from there. But if the re-design doesn't use them, adjusting their designs to the ones I need will bring more pain than they solve. So it's an instant NO for this case.

I could use one of the "headless" UI libraries like Radix or React Aria. Those implement the functionality like state and trigger and all the accessibility but leave the design to the consumer. While looking at their API, I would need to double-check that they allow me to control the state of the dialog if I really need it for the cases where I want to trigger the dialog manually (they do).

If, for some reason, I can't use the headless libraries, I would at least try to use a library that handles the focus trap functionality.

For the sake of the article, let's assume that I can bring any library that I want. In this case, I'll go with Radix - it's very easy to use, and the API of the dialog looks very similar to what I already implemented, so refactoring should be a breeze.

We would need to change the API of the dialog itself a bit:

export const ModalDialog = ({
  trigger,
  size,
  ...props
}) => {
  const className = `dialog ${size}`;
  return (
    <Dialog.Root {...props}>
      <Dialog.Trigger asChild>{trigger}</Dialog.Trigger>
      <Dialog.Portal>
        <Dialog.Overlay className="backdrop" />
        <Dialog.Content className={className}>
          {props.children}
          <Dialog.Close asChild>
            <button className="close" aria-label="Close">
              <CloseIcon />
            </button>
          </Dialog.Close>
        </Dialog.Content>
      </Dialog.Portal>
    </Dialog.Root>
  );
};

It's pretty much the same as I had before. Only, instead of divs everywhere, I use Radix primitives.

The uncontrolled dialog usage doesn't change at all:

export default function Page() {
  return (
    <>
      <ModalDialog
        trigger={
          <button>
            open uncontrolled non-standard dialog
          </button>
        }
        size="medium"
      >
        <DialogHeader>Header</DialogHeader>
        <DialogContent>Content</DialogContent>
        <DialogFooter>
          <button>confirm</button>
          <button>deny</button>
        </DialogFooter>
      </ModalDialog>
    </>
  );
}

And controlled dialog changes slightly - I would need to pass props to it instead of conditional rendering:

export default function Page() {
  // still able to control state if I need
  const [isOpenStandard, setIsOpenStandard] =
    useState(false);
  return (
    <>
      <button onClick={() => setIsOpenStandard(true)}>
        open controlled standard dialog
      </button>
      <ModalDialog
        size="medium"
        // just need to pass that state here
        open={isOpenStandard}
        // and listen for the change here
        onOpenChange={() => {
          setIsOpenStandard(false);
        }}
      >
        <DialogHeader>Header</DialogHeader>
        <DialogContent>Content</DialogContent>
        <DialogFooter>
          <button>confirm</button>
          <button>deny</button>
        </DialogFooter>
      </ModalDialog>
    </>
  );
}

Check out the example below and try to use the keyboard to navigate. Everything works as I need it, how cool is that?

As a bonus, Radix also handles the Portal issue, and it doesn't wrap triggers in a span. I don't have edge cases to solve anymore, so I can move on to the last step.

Step 6: final polish

The feature is still not done! 😅 The dialog looks and feels pretty solid now, so I'm not going to change anything major in its implementation at this stage. But it still needs a few things to be considered "perfect" dialog for the use case I'm solving.

One: the very first things the designers will ask me to do, if they haven't yet, is to add a subtle animation for when the dialog opens. Would need to anticipate it and remember how to do animations in React.

Two: I would need to add max-width and max-height to the dialog so that on small screens it still looks decent. And think about how it would look like on very large screens.

Three: I would need to talk to the designers about how the dialog should behave on mobile. Chances are they will ask me to make it a slide-in panel that takes most of the screen regardless of the size of the dialog.

Four: I would need to introduce at least DialogTitle and DialogDescription components - Radix will ask to use them for accessibility purposes.

Five: Tests! The dialog is here to stay and will be maintained by other people, so tests are pretty much mandatory in this case.

And probably tons of other small things I forgot now which will come up later. Not to mention implementing the actual designs for the dialog's content.

A few more thoughts

If you replace the "dialog" above with "SomeNewFeature," this is more or less the algorithm I use for implementing pretty much everything new.

Quick "spike" of the solution(s) → gather requirements for the feature → make it work → make it performant → make it complete → make it perfect.

For something like the actual dialog, which I've implemented hundreds of times by now, I'll do the first step in 10 seconds in my head and start with Step 2 right away.

For something very complicated and unknown, Step 1 might be longer and involve exploring different solutions and libraries right away.

Something not exactly unknown, just a "regular feature we need to do," might skip Step 1 as there might be nothing to explore.

Quite often, especially in the "agile" environments, it will be more of a spiral than a straight line, where requirements are provided incrementally and often change, and we're returning to the first two steps regularly.

Hope this type of article was useful! 💪🏼 Let me know if you'd want to have more content like this or would rather prefer the usual "how things work" stuff.

And looking forward to hearing how this process is different in y'all heads 😅

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter or Bluesky to get notified as soon as the next article comes out.

And btw, one last thing: if you're starting a new project soon and don't have a designer and the time to polish the design experience like described - I recently spent hours and hours (and hours) implementing a new library of UI components for this case. It has copy-pastable components and common patterns, Radix and Tailwind, dark mode, accessibility, and mobile support out-of-the-box. Including the perfect modal dialog above! 😅

Give it a try: https://www.buckets-ui.com/

Intro to CSS animations for React developers

Nadia Makarevich — Fri, 04 Oct 2024 09:11:39 +0000

How do y'all feel about CSS animations? Unless you're a big CSS connoisseur, I suspect you're like me, and the answer will be, "I copy-paste snippets with some magic inside from all over the internet and hope it works 😅."

Time to change that! Today, let's simplify CSS animations in our React apps. "React apps" is key here, btw 😉. Doing animations in React properly involves not only knowing about the CSS part but also understanding the React lifecycle and how it renders and updates DOM elements.

And in the process, let's implement some cool and useful stuff like expandable search field, smooth hover and focus transitions, cards that "pop" slightly, and a few variations of drawers that can slide in and out of the screen.

Expandable search field with CSS transition

Let's start with the simplest case. Have you ever seen a search field that expands when you click or tab to it? I want that!

And it's pretty easy to achieve. All we need is for an input field to have a width property and then change it to another width on :focus. Input field itself:

<input type="text" className="search-input" placeholder="Search..." />

Its CSS:

.search-input {
  ...
  width: 5rem;

  &:focus {
    width: 20rem;
  }
}

This will change the width of the search field from 5 to 20 rem when the input is focused. However, the transition to the new width will be instantaneous, nothing fancy.

To fix this, we need the CSS transition property. The API, at first glance, is a bit complicated. But in short, it's a property that tells the browser how to transition a style from one value to another gradually when that value changes.

All we need is to add a transition to the search that declares what to transition and how fast, and we're good:

.search-input {
  ...
  transition: width 300ms;
}

Now, when the width property changes for any reason, like us changing it on focus, the transition between values will take 300ms and will be silky smooth.

Check it out in the code example below.

Improving hover and focus on buttons with CSS transition

We're not limited to just width with transitions, by the way. Almost any CSS property can be transitioned. For example, when implementing buttons, we typically change their background on hover and add a ring on focus:

.button {
  ...
  background: #ffd7d5;

  &:hover {
    background: #e2a9a7;
  }

  &:focus {
    box-shadow: 0 0 0 2px #f95e5a;
  }
}

These effects, again, will be instantaneous. To make them smooth, we can add a transition to both background and box-shadow:

.button {
  transition: background 300ms, box-shadow 300ms;
}

or even use all and make sure absolutely anything that changes in a button is transitioned:

.button {
  transition: all 300ms;
}

Now, hover and focus have an animated effect to them, check it out:

Tabs: triggering transitions with React state change

Let's finally do some React now. In React, when we need to change something on the screen, we change the state. For example, if I were implementing something like tabs, I would store the name of the current tab in the state and assign the isActive property to the selected tab button:

export default function App() {
  const [active, setActive] = useState("first");
  return (
    <>
      <div className="button-group">
        <Button
          isActive={active === "first"}
          onClick={() => setActive("first")}
        >
          First
        </Button>
        ...
      </div>
    </>
  );
}

In Button, I'd change the styling of the button based on the isActive prop:

const Button = ({ isActive, onClick, children }: ButtonProps) => {
  return (
    <button className={isActive ? "active" : "normal"} onClick={onClick}>
      {children}
    </button>
  );
};

With CSS being something like this:

 button {
   ...
   &.active {
      background: #e2a9a7;
    }

    &.normal {
      background: #ffd7d5;
    }
 }

How do I make the transition between normal and active background smooth with this setup?

Well, actually, in exactly the same way as we did it with hover:

button {
  transition: all 200ms;
}

For transitions to work, it doesn't really matter where the change is coming from. All that matters is that a DOM element is rendered on the screen with one value in the "transitioned" property, and then this value is updated in any way.

As we know, when React re-renders an element (i.e., Button) due to state change, it updates its DOM rather than destroying and re-creating it from scratch. So first, the button is rendered with the normal class and it receives the background style from it. Second, when the state changes and the button receives the isActive="true" prop, it's re-rendered, and it receives the active class instead of normal. The background style changes on the existing button's DOM element from one value to another. The browser is smart enough to make the transition work.

However, what will happen if, for some reason, that button is forced to re-mount? We can easily imitate this by creating the Button component inside the App component:

export default function App() {
  const [active, setActive] = useState("first");

  // creating the button inside - don't do this in real apps!
  const Button = () => ...

  return (
    <>
      <div className="button-group">
        <Button
          isActive={active === "first"}
          onClick={() => setActive("first")}
        >
          First
        </Button>
        ...
      </div>
    </>
  );
}

In this case, on every state update, all the mounted buttons will unmount first. Their DOM elements and all of their styles will be destroyed, and the new DOM elements will be re-created from scratch. There will be no changes in the styles of existing DOM elements. As a result, transitions won't work. Yet another reason to never create components inside other components.

See for yourself here:

If you're not sure why this unmounting happens, I wrote a few deep dives on the topic, for example: https://www.developerway.com/posts/reconciliation-in-react. Or watch my YouTube video course, it covers it in detail: https://www.youtube.com/playlist?list=PL6dw1BPCcLC4n-4o-t1kQZH0NJeZtpmGp.

Making cards larger on hover with transform and transition

Transitions are not limited to just our regular colors or dimensions. They do real miracles when combined with transform - another CSS property that is rarely used to build interfaces but is invaluable when it comes to animations.

Imagine I render a gallery of cards on the screen:

<div className="card-group">
  <a href="#" className="card">
    <img src="url" alt="Happy life" />
  </a>
  ...
  // more cards
</div>

And I want to make a card slightly "pop" on hover, make it a bit bigger. How?

I could, of course, just make the width of a card slightly larger:

.card {
  width: 8rem;

  &:hover {
    width: 9rem;
  }
}

But that change will make all other cards move since I'm changing the layout of the gallery that way, making the entire gallery janky. I could try to mitigate it with negative margins, but that's quite complicated and fragile.

A much better solution is to use transform on the card and scale it a bit:

.card {
  ...

  &:hover {
    transform: scale(1.04);
  }
}

transform allows us to scale, rotate, or move elements on the screen without modifying the underlying layout of the page and disrupting the normal document flow. If I apply transform to any of the cards, everything around it will be rendered as if the card is still there, completely untransformed.

In theory, I can make that card fly around the page, rotate in the process, jump around every corner, and then return it back if I want to, and the rest of the page won't notice or care. But let's not go wild here and restrict ourselves to making the card slightly scaled and moving it a bit up:

.card {
  ...

  &:hover {
    transform: scale(1.04) translateY(1rem);
  }
}

Then, add a transition to make the behavior smooth:

.card {
  transition: all 300ms;

  &:hover {
    transform: scale(1.04) translateY(1rem);
  }
}

Maybe even add a bit of a delay to prevent the cards from moving around when moving the mouse over them fast:

.card {
  transition: all 300ms;
  transition-delay: 200ms;

  &:hover {
    transform: scale(1.04) translateY(1rem);
  }
}

The end result is basically perfection:

Implementing sliding drawer with simple transition

Enough of the minor hover effects. Now, it's time to get real and implement something more complicated. Let's implement something that pretty much every website needs these days: a drawer that can slide in from outside the screen when needed and then slide back out when dismissed.

We'll have an app, a state for the drawer's "openness", a button that triggers that state, and the drawer itself:

const App = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      <button onClick={() => setIsOpen(!isOpen)}>
        toggle drawer
      </button>
      {isOpen ? <div className="drawer open">... drawer content</div> : null}
    </>
  );
};

This is pretty standard code. When the state is true, we render the drawer; when it's false, we remove it. (Notice a catch here? 😉 Keep reading!)

Now, onto the CSS. We'll have two classes: a normal drawer for when the drawer is closed, and open for when it's, obviously, open. We'll position the drawer at the right end of the screen:

.drawer {
  width: 22rem;
  height: 100vh;
  position: fixed;
  top: 0;
  right: 0;
}

Move it outside the screen with the transform property:

.drawer {
  ...
  transform: translateX(24rem);
}

And transform it back to 0 when the drawer has the .open class:

.drawer {
  ...
  transform: translateX(24rem);

  &.open {
    transform: translateX(0);
  }
}

The drawer here will appear instantly, which makes sense - we haven't added any transition yet.

Let's add it:

.drawer {
  ...
  transition: transform 600ms;
}

And we should be good!

Except we're not 😢. The animation doesn't happen. The drawer still appears instantly. Do you know why, without looking at the solution?

The answer is here:

const App = () => {
  ...

  return (
    <>
      ...
      {isOpen ? <div className="drawer open">... drawer content</div> : null}
    </>
  );
};

Remember we discussed mounting/unmounting when we were implementing tabs?

When the isOpen state changes to true, we're mounting the drawer from scratch. When it switches back to false, we're unmounting and deleting it. There is no transition of CSS properties! The transform property is applied only once - when the drawer opens and mounts.

To fix this, we need to make sure that the open class is added or removed from the drawer that is always mounted. This forces React to update the div styles, which will trigger the transition:

const App = () => {
  ...

  return (
    <>
      ...
      <div className={`drawer ${isOpen ? 'open' : ''}`}>... drawer content</div>
    </>
  );
};

Now, the drawer finally works as intended! Check it out, nice and smooth:

There is, however, one caveat in this animated miracle. Hope you noticed it already.

When we switched to manipulating class names rather than unmounting the drawer, we did a terrible thing: we now always render the entire drawer content when the page is loaded.

For a tiny "how do you like my article" drawer with a single button, that might be okay. For a large app with multiple heavy drawers, that could slow it down badly. Especially if you're fetching some data there - all the requests will be fired as soon as the drawer is mounted.

What I need is a way to animate that drawer right when it's mounted without waiting for a transition. This brings me to the last piece of that animated puzzle: CSS animation property and keyframes.

Implementing sliding drawer with animation and keyframes

The CSS animation property allows us to apply transitions to an element without waiting for any state changes or hover events. Right after it's mounted - exactly what we need.

It consists of two parts. First is the animation property itself, which allows us to configure which animation to apply to an element and all the other necessary parameters like the duration or delay of the animation. More or less the same as the transition property.

For our drawer, it could look like this:

.drawer {
  &.slide-in {
    animation: slidein 600ms;
  }

  &.slide-out {
    animation: slideout 600ms;
  }
}

The .slide-in class has the animation property that applies the slidein animation with a 600ms duration. The same goes for .slide-out, only the animation name is slideout.

The second part is to describe what those named animations should do. This is the job of keyframes. Keyframes allow us to implement very granular and complicated movements, but the simplest version is just to define from and to. This will transition styles on an element from one value to another.

@keyframes slidein {
  from {
    transform: translateX(24rem);
  }

  to {
    transform: translateX(0);
  }
}

This is our slidein animation - it transforms the drawer from behind the screen to visibility. Exactly the same as we did in the first drawer.

The slideout will be the same, only in reverse.

@keyframes slideout {
  from {
    transform: translateX(0);
  }

  to {
    transform: translateX(24rem);
  }
}

And the final step is to apply those class names to our drawer:

const App = () => {
  ...

  return (
    <>
      ...
      {isOpen ? (
        <div className={`drawer ${isOpen ? "slide-in open" : "slide-out"}`}>
          ... drawer content
        </div> : null
      }
    </>
  );
};

Notice that isOpen prevents the drawer from rendering when it's false - exactly what I needed. And it actually works, the drawer opens with animation without being pre-rendered! 🎉

With one caveat - the slide-out animation didn't happen. The drawer just disappears instantly. This actually might be fine for a lot of use cases, so here's the working example to play around with:

However, if you want the full experience, with the drawer sliding out with animation as well, we need to fix it. I hope, at this point, you have a good understanding of how all of this works and can instantly point out why it happens.

The problem lies in unmounting: when we flip the isOpen state to false, React instantly removes the drawer from the DOM. The animation just doesn't have a chance to run 🥺.

To fix this, we need to introduce a "transitional" state - so that we can keep the drawer mounted while the animation is running and unmount it when it's done.

We'll have the state itself:

const [isAnimating, setIsAnimating] = useState(false);

We'll add a ref and assign it to the drawer so that we can listen for animation-related events:

const drawerRef = useRef<HTMLDivElement>(null);

...
<div className={`drawer ...}`} ref={drawerRef}>
  ... drawer content
</div>

Add event listeners for animationcancel and animationend events to catch when the animation is done:

useEffect(() => {
  drawerRef.current?.addEventListener("animationcancel", () => {
    setIsAnimating(false);
  });
  drawerRef.current?.addEventListener("animationend", () => {
    setIsAnimating(false);
  });
}, [drawerRef.current]);

Flip the isAnimating state to true when we open/close the drawer:

<button
  className="button"
  onClick={() => {
    setIsOpen(!isOpen);
    setIsAnimating(true);
  }}
>
  toggle the drawer
</button>

And finally, keep the drawer mounted while the animation is running, i.e., isAnimating is true:

const App = () => {
  ...

  return (
    <>
      ...
      {isOpen || isAnimating ? (... /* drawer here */) : null
      }
    </>
  );
};

Phew! That's a lot of stuff, but finally, we have a perfect drawer with slide-in and slide-out animation. Check it out here:

By the way, do you know what we just did? We implemented a very rudimentary version of the react-transition-group library 😅. So, we might as well just use it instead of trying to manage additional state and events manually.

Implementing sliding drawer with react-transition-group

react-transition-group is a library that encapsulates the logic of tracking the animation state into a few components. For our drawer, we can use the Transition component. It does pretty much what we did in the previous step. Only in addition, it manages when the transition starts and gives us that state in the form of a component with good old render props.

We'd still need our isOpen state and the ref we'll attach to the animated element:

const App = () => {
  const ref = useRef(null);
  const [isOpen, setIsOpen] = useState(false);
}

But that's pretty much it. The rest of the code is to render the Transition component and the drawer inside:

<Transition
  nodeRef={ref}
  timeout={600}
  in={isOpen}
  mountOnEnter
  unmountOnExit
>
  {() => {
    return (
      <div
        ref={ref}
        className={`drawer ${
          isOpen ? "open-animated" : "close-animated"
        }`}
      >
        ...drawer content
      </div>
    );
  }}
</Transition>

The important things in this code are:

in - this is where we'd send our state that controls the drawer's visibility.
mountOnEnter and unmountOnExit - these will make sure that our drawer mounts/unmounts when it's open/close. So that we don't end up with an always-rendered drawer from the very first example.
nodeRef={ref} - don't forget to pass the ref from the div here as well.

🎉 And it just works!

Check it out here:

Pretty cool what's possible today, right? Hope now you'll be able to organize and lead a "CSS Animations Appreciation Society" in your company. Or at least be able to implement nice animated elements easily and show off in front of your colleagues 💪🏼.

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

Replacing React code with CSS :has selector

Nadia Makarevich — Mon, 16 Sep 2024 11:43:00 +0000

Since the dawn of time… okay, since the beginning of CSS at least, we have been taught that CSS is cascading. It's literally in the name, they are Cascading Style Sheets. Via CSS, an element can target an element inside of it, then an element inside, etc. But never, ever in the reverse order. An element can not apply styles to a parent element by any means other than via JavaScript.

Until now.

The CSS :has selector is now supported by all major browsers, and with it, we actually can now target parent elements. And more! The world, indeed, is turned upside down. If you, like me, started your dev career in those blessed times when we were doing round corners on elements via transparent GIFs, the possibilities today will blow your mind.

So, other than being a cool new toy, what practical use does it actually have in the React world? Let's take a look at three very exciting ones.

What is the :has selector?

If you remember, in "standard" CSS, we can do this:

.content .card {
  background: #f0f0f0;
}

.content img {
  margin: 1rem 0;
}

This changes the background of a .card element inside a .content element to light grey and adds margins to images inside. So that it's visually separated from the text.

We can also select the next sibling with + or ~ combinators. For example, if this image is right after the .card element, we might want to add an additional margin to it so that it's even more visually separated.

// images that immediately follow a card element
// will have bigger margins than other images
.content .card + img {
  margin: 2rem 0;
}

Check out the code example here.

However, until recently, we couldn't select elements in the "opposite" direction. If I wanted to change the background of a .card element that is immediately followed by an image, for example, that would've been impossible without JavaScript. Or to style the .card differently if it had an image inside - also nope.

The new CSS selector :has fixes that.

I want to have pink borders on my .card elements with images inside and grey borders on all the others? Easy peasy!

// all the cards will have grey top borders
.card {
  border-top: 10px solid #f6f7f6;
}

// cards with images inside will have pink borders
.card:has(img) {
  border-top: 10px solid #fee6ec;
}

The :has selector works with other selectors too. I also want to add blue borders on cards that are followed by an image? Sure thing! We can check that condition with the + combinator.

// if a card has an image as a next element - give it a blue border
.card:has(+ img) {
  border-top: 10px solid #c4f4ff;
}

We can even go crazy and code something like "apply a green background to a .card element that does not have an h3 tag inside, has an img tag inside, has another .card element immediately after, and an img tag anywhere after that, but only if it's followed by a card with more than one image".

// have fun reading that ;)
.card:not(:has(h3)):has(img):has(+ .card):has(~ img):has(~ .card):has(> img:nth-child(1)) {
  background-color: #c3dcd0;
}

Check out the implemented example below.

However, when it comes to our React apps, is this really something we want to do? Styles like that are heavily leaking through component boundaries, the same as child selectors. Didn't we spend the last decade or so inventing creative ways to prevent exactly that? BEM, SASS, CSS-in-JS, CSS modules… We do everything in our power to scope the styling only to the elements it's assigned to.

Why would we suddenly revert everything and do the opposite of all the best practices? Other than the fact that we tend to do that every few years in React anyway, of course 😅

The answer: so that we can remove a bunch of complicated React code! Sometimes, the best React code is no React code. And despite the last crazy selector (seriously, don't do that to your colleagues), replacing React with CSS can simplify the logic and even sometimes improve performance a bit.

Let's take a look at some practical examples of that.

:has selector and focus state on elements

Imagine we're implementing a task board. The board will have a bunch of cards, each card has two buttons: "open" and "delete". Clicking on the "open" button will open the full content of the card in a modal. Clicking on "delete" deletes the card.

The card's code here is trivial:

<div className="card">
  Some text here
  <div className="buttons">
    <button>
      <Open />
    </button>
    <button>
      <Delete />
    </button>
  </div>
</div>

We want it to be fully keyboard accessible: tabbing to those buttons should work. On top of that, I want the cards to highlight which button is tabbed into to improve accessibility for keyboard users. When a user tabs to any of those buttons, I want the card to "pop" slightly and the other cards in the column to grey out. Plus, I want to change the border color of the active card to highlight the current active interaction. Red for the "delete" button, and green for the "open" button.

If we were to implement this functionality with React, we'd have to add a focus event listener, detect which button is currently active, maintain the state so that we can change the classNames on the card itself, and somehow share that state with the parent so that other cards can be changed as well. We would probably have to introduce Context or some other state management solution for it. Before you know it, we'd have to implement a full-blown focus manager that re-renders every card on every tab. No wonder we don't see this fancy interactivity in the real world, and the best we can hope for is consistent outlines on buttons.

With the :has selector, however, it's more or less trivial to implement what I just described.

First step. Assign some data- attributes to the buttons so that we can select them without relying on className:

// add data-action attributes to the buttons
<button data-action="open">
  <Open />
</button>
<button data-action="delete">
  <Delete />
</button>

Second step. Find the card with the focused "delete" button inside and change its CSS:

// make the card "pop" and change its border colors
// if the "delete" button inside the card is focused
.card:has([data-action='delete']:focus-visible) {
  border-top: 10px solid #f7bccb;
  box-shadow: 0 0 0 2px #f7bccb;
  transform: scale(1.02);
}

Third step. Find the card with the focused "open" button inside and change its CSS:

// make the card "pop" and change its border colors
// if the "open" button inside the card is focused
.card:has([data-action='open']:focus-visible) {
  transform: scale(1.02);
  border-top: 10px solid #c3dccf;
  box-shadow: 0 0 0 2px #c3dccf;
}

Forth step. This is the hardest one: we need to find all the cards before and after the card with focused open or delete buttons and then grey them out. The magic:

// all cards after the card with focused "open" button
.card:has([data-action='open']:focus-visible) ~ .card,

// all cards after the card with focused "delete" button
.card:has([data-action='delete']:focus-visible) ~ .card,

// all cards before the card with focused "open" button
.card:has(~ .card [data-action='open']:focus-visible),

// all cards before the card with focused "delete" button
.card:has(~ .card [data-action='delete']:focus-visible) {
  filter: greyscale();
  background-color: #f6f7f6;
}

The end result: the most beautiful keyboard navigation in all the boards ever with zero JavaScript and zero React re-renders! A live example is below to play around with.

:has selector and categories of stuff

Another use case for the :has selector that I find fascinating in its simplicity is color-coding stuff based on some data.

For example, let's implement a table with products that are sold in our shop. These products fit into specific categories: let's say we're selling office supplies, clothes, and horses online. The table will have a few columns and, in its simplest form, will look something like this:

and be coded like this:

...
<tr>
  <td>Socks</td>
  <td>Created by...</td>
  <td>Inventory full</td>
  <td>
    <span className="category">
      clothes
    </span>
  </td>
</tr>
...

Now, I want to subtly highlight which row belongs to which category by drawing a border on the left with the category's color. And when an inventory is empty, I want to highlight that row with a red background so that people pay attention to it. This is how I want it to look:

In React, we'd have to pass information about the category and the inventory through props to at least the row tag, maybe even the first cell. And create class names or even internal components for every variation. Totally unnecessary complication in this case.

Instead, we can just do this.

Step 1. Add data- attributes with the information to the cells that already have that information.

<tr>
  <td>Socks</td>
  <td>Created by...</td>
  <!-- add data-inventory attribute here -->
  <td data-inventory="full">Inventory full</td>
  <td>
    <!-- add data-category attribute here -->
    <span className="category" data-category="clothes">
      clothes
    </span>
  </td>
</tr>

Step 2. Color-code everything we need with the help of the :has attribute.

Add different colored borders to the first cell of the row if the row has an element with the data-category attribute.

.table tr:has([data-category='clothes']) td:first-child {
  border-left: 6px solid #f7bccb;
}

.table tr:has([data-category='office']) td:first-child {
  border-left: 6px solid #f4d592;
}

.table tr:has([data-category='animals']) td:first-child {
  border-left: 6px solid #c4f4ff;
}

Add the red background if the row has an element with the data-inventory attribute with the empty value.

.table tr:has([data-inventory='empty']) {
  background: #f6d0ce;
}

And voila - the table is beautifully color-coded. The coolest part here is that if those attributes come from a dynamic state and tend to be updated frequently, the entire row won't have to re-render to update the colors! Only the cell with the data-attribute. Again, a tiny potential performance improvement in addition to the cleaner code.

Check out the interactive example below.

:has selector and form elements

And finally, a very powerful use case for the:has selector that I really like is styling elements based on the form elements' state.

For example, in a form where inputs can be disabled, we can also visually "disable" the input's label and description.

The code for this form will look something like this:

 <form className="form">
  <fieldset>
    <label htmlFor="form-name">Name</label>
    <input type="text" name="name" id="form-name" disabled value="Nadia" />
    <div className="description">Just your first name is fine</div>
  </fieldset>

  <fieldset>
    <label htmlFor="form-email">Email Address</label>
    <input type="email" name="email" id="form-email" required />
    <div className="description">We don't accept gmail domains!</div>
  </fieldset>
</form>

Then in CSS, we'd target a fieldset that has an input with the :disabled state, and style label and .description elements.

fieldset:has(input:disabled) label,
fieldset:has(input:disabled) .description {
  color: #d6d6d6;
}

Focus, of course, will also work. If we want to add a line at the left when the input is focused,

we can just do this:

fieldset:has(input:focus-visible) {
  border-left: 10px solid #c4f4ff;
}

Or, if we're implementing a list with checkboxes, we can easily highlight the "checked" row without even storing the checkbox's state and creating an .active class, as we usually do for situations like this.

All we need is a CSS selector:

.list-with-checkboxes li:has(input:checked) {
  background: rgba(196, 244, 255, 0.3);
}

Here's the live preview, check it out:

How cool is all of this, right? What's your favorite :has-related trick? Share in the comments!

Of course, there are many more good opportunities to simplify our React code with clever selectors. These are just a few examples that I particularly liked. If you want to learn more about the :has selector and play around with more cool examples, here's the list of articles I particularly liked that have plenty of those:

By looking at how CSS has progressed in recent years, maybe in five-ish years, we won't need React at all. 🤯 What an interesting day that would be!

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

I tried React Compiler today, and guess what... 😉

Nadia Makarevich — Mon, 10 Jun 2024 08:18:00 +0000

This is probably the most clickbaity title I’ve come up with, but I feel like an article about one of the most hyped topics in the React community these days deserves it 😅.

For the last two and a half years, after I release any piece of content that mentions patterns related to re-renders and memoization, visitors from the future would descend into the comments section and kindly inform me that all I just said is not relevant anymore because of React Forget (currently known as React Compiler).

Now that our timeline has finally caught up with theirs and React Compiler is actually released to the general public as an experimental feature, it’s time to investigate whether those visitors from the future are correct and see for ourselves whether we can forget about memoization in React starting now.

What is React Compiler

But first, very, very briefly, what is this compiler, what problem does it solve, and how do you get started with it?

The problem: Re-renders in React are cascading. Every time you change state in a React component, you trigger a re-render of that component, every component inside, components inside of those components, etc., until the end of the component tree is reached.

If those downstream re-renders affect some heavy components or happen too often, this might cause performance problems for our apps.

One way to fix those performance problems is to prevent that chain of re-renders from happening, and one way to do that is with the help of memoization: React.memo, useMemo, and useCallback. Typically, we’d wrap a component in React.memo, all of its props in useMemo and useCallback, and next time, when the parent component re-renders, the component wrapped in memo (i.e., “memoized”) won’t re-render.

But using those tools correctly is hard, very hard. I’ve written a few articles and done a few videos on this topic if you want to test your knowledge of it (How to useMemo and useCallback: you can remove most of them, Mastering memoization in React - Advanced React course, Episode 5).

This is where React Compiler comes in. The compiler is a tool developed by the React core team. It plugs into our build system, grabs the original components' code, and tries to convert it into code where components, their props, and hooks' dependencies are memoized by default. The end result is similar to wrapping everything in memo, useMemo, or useCallback.

This is just an approximation to start wrapping our heads around it, of course. In reality, it does much more complicated transformations. Jack Herrington did a good overview of that in his recent video (React Compiler: In-Depth Beyond React Conf 2024), if you want to know the actual details. Or, if you want to break your brain completely and truly appreciate the complexity of this, watch the “React Compiler Deep Dive” talk where Sathya Gunasekaran explains the Compiler and Mofei Zhang then live-codes it in 20 minutes 🤯.

If you want to try out the Compiler yourself, just follow the docs: https://react.dev/learn/react-compiler. They are good enough already and have all the requirements and how-to steps. Just remember: this is still a very experimental thing that relies on installing the canary version of React, so be careful.

That’s enough of the preparation. Let’s finally look at what it can do and how it performs in real life.

Trying out the Compiler

For me, the main purpose of this article was to investigate whether our expectations of the Compiler match reality. What is the current promise?

The Compiler is plug-and-play: you install it, and it Just Works; there is no need to rewrite existing code.
We will never think about React.memo, useMemo, and useCallback again after it’s installed: there won’t be any need.

To test those assumptions, I implemented a few simple examples to test the Compiler in isolation and then ran it on three different apps I have available.

Simple examples: testing the Compiler in isolation

The full code of all the simple examples is available here: https://github.com/developerway/react-compiler-test

The easiest way to start with the Compiler from scratch is to install the canary version of Next.js. Basically, this will give you everything you need:

npm install next@canary babel-plugin-react-compiler

Then we can turn the Compiler on in the next.config.js:

const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};

module.exports = nextConfig;

And voila! We’ll immediately see auto-magically memoized components in React Dev Tools.

The assumption one is correct so far: installing it is pretty simple, and it Just Works.

Let’s start writing code and see how the Compiler deals with it.

First example: simple state change.

const SimpleCase1 = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>
        toggle dialog
      </button>
      {isOpen && <Dialog />}
      <VerySlowComponent />
    </div>
  );
};

We have an isOpen state variable that controls whether a modal dialog is open or not, and a VerySlowComponent rendered in the same component. Normal React behavior would be to re-render VerySlowComponent every time the isOpen state changes, leading to the dialog popping up with a delay.

Typically, if we want to solve this situation with memoization (although there are other ways, of course), we’d wrap VerySlowComponent in React.memo:

const VerySlowComponentMemo = React.memo(VerySlowComponent);

const SimpleCase1 = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      ...
      <VerySlowComponentMemo />
    </>
  );
};

With the Compiler, it’s pure magic: we can ditch the React.memo, and still see in the dev tools that the VerySlowComponent is memoized, the delay is gone, and if we place console.log inside the VerySlowComponent, we’ll see that indeed, it’s not re-rendered on state change anymore.

The full code of these examples is available here.

Second example: props on the slow component.

So far so good, but the previous example is the simplest one. Let’s make it a bit more complicated and introduce props into the equation.

Let’s say our VerySlowComponent has an onSubmit prop that expects a function and a data prop that accepts an array:

const SimpleCase2 = () => {
  const [isOpen, setIsOpen] = useState(false);

  const onSubmit = () => {};
  const data = [{ id: 'bla' }];

  return (
    <>
      ...
      <VerySlowComponent onSubmit={onSubmit} data={data} />
    </>
  );
};

Now, in the case of manual memoization, on top of wrapping VerySlowComponent in React.memo, we’d need to wrap the array in useMemo (let’s assume we can’t just move it outside for some reason) and onSubmit in useCallback:

const VerySlowComponentMemo = React.memo(VerySlowComponent);

export const SimpleCase2Memo = () => {
  const [isOpen, setIsOpen] = useState(false);

  // memoization here
  const onSubmit = useCallback(() => {}, []);

  // memoization here
  const data = useMemo(() => [{ id: 'bla' }], []);

  return (
    <div>
      ...
      <VerySlowComponentMemo
        onSubmit={onSubmit}
        data={data}
      />
    </div>
  );
};

But with the Compiler, we still don’t need to do that! VerySlowComponent still appears as memoized in React dev tools, and the “control” console.log inside it is still not fired.

You can run these examples locally from this repo.

Third example: elements as children.

Okay, the third example, before testing a real app. What about the case where almost no one can memoize correctly? What if our slow component accepts children?

export const SimpleCase3 = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      ...
      <VerySlowComponent>
        <SomeOtherComponent />
      </VerySlowComponent>
    </>
  );
};

Can you, off the top of your head, remember how to memoize VerySlowComponent correctly here?

Most people would assume that we’d need to wrap both VerySlowComponent and SomeOtherComponent in React.memo. This is incorrect. We'd need to wrap our <SomeOtherComponent /> element into useMemo instead, like this:

const VerySlowComponentMemo = React.memo(VerySlowComponent);

export const SimpleCase3 = () => {
  const [isOpen, setIsOpen] = useState(false);

  // memoize children via useMemo, not React.memo
  const child = useMemo(() => <SomeOtherComponent />, []);

  return (
    <>
      ...
      <VerySlowComponentMemo>{child}</VerySlowComponentMemo>
    </>
  );
};

If you’re unsure why this is the case, you can watch this video that explains memoization in detail, including this pattern: Mastering memoization in React - Advanced React course, Episode 5. This article can also be useful: The mystery of React Element, children, parents and re-renders

Luckily, the React Compiler still works its magic ✨ here! Everything is memoized, the very slow component doesn’t re-render.

Three hits out of three so far, that’s impressive! But those examples are very simple. When’s life that easy in reality? Let’s try a real challenge now.

Testing the Compiler on real code

To really challenge the Compiler, I ran it on three codebases I have available:

App One: A few years old and quite large app, based on React, React Router & Webpack, written by multiple people.
App Two: Slightly newer but still quite large React & Next.js app, written by multiple people.
App Three: My personal project: very new, latest Nextjs, very small - a few screens with CRUD operations.

For every app, I did:

initial health check to determine the readiness of the app for the Compiler.
enabled Compiler’s eslint rules and ran them on the entire codebase.
updated React version to 19 canary.
installed the Compiler.
identified some visible cases of unnecessary re-renders before turning on the Compiler.
turned on the Compiler and checked whether those unnecessary re-renders were fixed.

Testing the Compiler on App One: results

This one is the biggest, probably around 150k lines of code for the React part of the app. I identified 10 easy-to-spot cases of unnecessary re-renders for this app. Some were pretty minor, like re-rendering a whole header component when clicking a button inside. Some were bigger, like re-rendering the entire page when typing in an input field.

Initial health check: 97.7% of the components could be compiled! No incompatible libraries.
Eslint check: just 20 rule violations
React 19 update: a few minor things broke, but after commenting them out, the app seemed to be working fine.
Installing the Compiler: this one produced a few F-bombs and required some help from ChatGPT since it’s been a while since I last touched anything Webpack or Babel-related. But in the end, it also worked.
Testing the app: out of 10 cases of unnecessary re-renders … only 2 were fixed by the Compiler 😢

2 out of 10 was a pretty disappointing result. But this app had some eslint violations that I haven’t fixed, maybe that’s why? Let’s take a look at the next app.

Testing the Compiler on App Two: results

This app is much smaller, something like 30k lines of React code. Here I also identified 10 unnecessary re-renders.

Initial health check: Same result, 97.7% components could be compiled.
Eslint check: just 1 rule violation! 🎉Perfect candidate.
React 19 update & installing the Compiler: for this, I had to update Next.js to the canary version, it took care of the rest. It just worked after the installation, was much easier than updating the Webpack-based app.
Testing the app: out of 10 cases of unnecessary re-renders… only 2 again were fixed by the compiler 😢

2 out of 10 again! On a perfect candidate… Again, a bit disappointing. That’s real life against synthetic “counter” examples for you. Let’s take a look at the third app before trying to debug what’s going on.

Testing the Compiler on App Three: results

This is the smallest of them all, written in a weekend or two. Just a few pages with a table of data, and the ability to add/edit/remove an entity in the table. The entire app is so small and so simple that I was able to identify only 8 unnecessary re-renders in it. Everything re-renders on every interaction there, I haven’t optimized it in any way.

Perfect subject for the React Compiler to drastically improve the re-renders situation!

Initial health check: 100% of components can be compiled
Eslint check: no violations 🎉
React 19 update & installing the Compiler: surprisingly worse than the previous one. Some of the libraries that I used were not compatible with React 19 yet. I had to force-install the dependencies to silence the warnings. But the actual app and all the libraries still worked, so no harm, I guess.
Testing the app: out of 8 cases of unnecessary re-renders, the React Compiler managed to fix… drum roll… one. Only one! 🫠 At this point, I almost started crying; I had such hopes for this test.

This is something that my old clinical nature expected, but definitely not something that my naive inner child was hoping for. Maybe I’m just writing React code wrong? Can I investigate what went wrong with memoization by the Compiler, and can it be fixed?

Investigating the results of memoization by the Compiler

To debug these issues in a useful manner, I extracted one of the pages from the third app into its own repo. You can check it out here: (https://github.com/developerway/react-compiler-test/ ) if you want to follow my train of thought and do a code-along exercise. It’s almost exactly one of the pages I have in the third app, just with fake data and a few things removed (like SSR) to simplify the debugging experience.

The UI is very simple: a table with a list of countries, a “delete” button for each row, and an input component under the table where you can add a new country to the list.

From the code perspective, it’s just one component with one state, queries, and mutations. Here’s the full code. The simplified version with only the necessary information for the investigation looks like this:

export const Countries = () => {
  // store what we type in the input here
  const [value, setValue] = useState("");

  // get the full list of countries with react-query
  const { data: countries } = useQuery(...);

  // mutation to delete a country with react-query
  const deleteCountryMutation = useMutation(...);

  // mutation to add a country with react-query
  const addCountryMutation = useMutation(...);

  // callback that is passed to the "delete" button
  const onDelete = (name: string) => deleteCountryMutation.mutate(name);

  // callback that is passed to the "add" button
  const onAddCountry = () => {
    addCountryMutation.mutate(value);
    setValue("");
  };

  return (
    ...
      {countries?.map(({ name }, index) => (
        <TableRow key={`${name.toLowerCase()}`}>
          ...
          <TableCell className="text-right">
            <!-- onDelete is here -->
            <Button onClick={() => onDelete(name)} variant="outline">
              Delete
            </Button>
          </TableCell>
        </TableRow>
      ))}
    ...
    <Input
      type="text"
      placeholder="Add new country"
      value={value}
      onChange={(e) => setValue(e.target.value)}
    />
    <button onClick={onAddCountry}>Add</button>
  );
};

Since it’s just one component with multiple states (local + query/mutation updates), everything re-renders on every interaction. If you start the app, you’ll have these cases of unnecessary re-renders:

typing into the “Add new country” input causes everything to re-render.
clicking “delete” causes everything to re-render.
clicking “add” causes everything to re-render.

For a simple component like this, I’d expect the Compiler to fix all of this. Especially considering that in the React Dev Tools, everything seems to be memoized:

However, try enabling the “Highlight updates when components render” setting and enjoy the light show.

Adding console.log to every component inside the table gives us the exact list: everything except for the header components still re-renders on every state update from all sources.

How to investigate why, though? 🤔

React Dev Tools doesn’t give any additional information. I could copy-paste that component into the Compiler Playground and see what happens… But take a look at the output! 😬 That feels like a step in the wrong direction, and to be frank, the last thing I want to do, ever.

The only thing that comes to mind is to incrementally memoize that table and see whether something fishy is going on with components or dependencies.

Investigating via manual memoization

This part is for those who fully understand how all manual memoization techniques work. If you’re feeling uneasy about React.memo, useMemo, or useCallback, I recommend watching this video first.

Also, I’d recommend opening the code locally (https://github.com/developerway/react-compiler-test ) and doing a code-along exercise; it would make following the train of thought below much easier.

Investigating typing into input re-renders

Let’s look at that table again, this time in full:

<Table>
  <TableCaption>Supported countries list.</TableCaption>
  <TableHeader>
    <TableRow>
      <TableHead className="w-[400px]">Name</TableHead>
      <TableHead className="text-right">Action</TableHead>
    </TableRow>
  </TableHeader>
  <TableBody>
    {countries?.map(({ name }, index) => (
      <TableRow key={`${name.toLowerCase()}`}>
        <TableCell className="font-medium">
          <Link href={`/country/${name.toLowerCase()}`}>
            {name}
          </Link>
        </TableCell>
        <TableCell className="text-right">
          <Button
            onClick={() => onDelete(name)}
            variant="outline"
          >
            Delete
          </Button>
        </TableCell>
      </TableRow>
    ))}
  </TableBody>
</Table>

The fact that header components were memoized hints to us what the Compiler did: it probably wrapped all components in a React.memo equivalent, and the part inside TableBody is memoized with a useMemo equivalent. And the useMemo equivalent has something in its dependencies that is updated with every re-render, which in turn causes everything inside TableBody to re-render, including TableBody itself. At least it’s a good working theory to test.

If I replicate the memoization of that content part, it might give us some clues:

// memoize the entire content of TableBody
const body = useMemo(
  () =>
    countries?.map(({ name }, index) => (
      <TableRow key={`${name.toLowerCase()}`}>
        <TableCell className="font-medium">
          <Link href={`/country/${name.toLowerCase()}`}>
            {name}
          </Link>
        </TableCell>
        <TableCell className="text-right">
          <Button
            onClick={() => onDelete(name)}
            variant="outline"
          >
            Delete
          </Button>
        </TableCell>
      </TableRow>
    )),
  // these are the dependencies used in that bunch of code
  // thank you eslint!
  [countries, onDelete],
);

Now it’s clearly visible that this entire part depends on the countries array of data and the onDelete callback. The countries array is coming from a query, so it can’t possibly be re-created on every re-render - caching this is one of the primary responsibilities of the library.

The onDelete callback looks like this:

const onDelete = (name: string) => {
  deleteCountryMutation.mutate(name);
};

In order for it to go into the dependencies, it should be memoized as well:

const onDelete = useCallback(
  (name: string) => {
    deleteCountryMutation.mutate(name);
  },
  [deleteCountryMutation],
);

And deleteCountryMutation is a mutation from react-query again, so it’s likely okay:

const deleteCountryMutation = useMutation({...});

The final step is to memoize the TableBody and render the memoized child. If everything is memoized correctly, then re-rendering of rows and cells when typing in the input should stop.

const TableBodyMemo = React.memo(TableBody);

// render that inside Countries
<TableBodyMemo>{body}</TableBodyMemo>;

Aaaand, it didn’t work 🤦🏻‍♀️ Now we’re getting somewhere - I messed something up with the dependencies, and the Compiler probably did the same. But what? Aside from countries, I only have one dependency - deleteCountryMutation. I made an assumption that it’s safe, but is it really? What’s actually inside? Luckily, the source code is available. useMutation is a hook that does a bunch of things and returns this:

const mutate = React.useCallback(...)

return { ...result, mutate, mutateAsync: result.mutate }

It’s a non-memoized object in the return!! I was wrong in my assumption that I could just use it as a dependency.

mutate itself is memoized, however. So in theory, I just need to pass it to the dependencies instead:

// extract mutate from the returned object
const { mutate: deleteCountry } = useMutation(...);

// pass it as a dependency instead
const onDelete = useCallback(
  (name: string) => {
    // use it here directly
    deleteCountry(name);
  },
  // hello, memoized dependency
  [deleteCountry],
);

After this step, finally, our manual memoization works.

Now, in theory, if I just remove all that manual memoization and leave the mutate fix in place, the React Compiler should be able to pick it up.

And indeed, it does! Table rows and cells don’t re-render anymore when I type something 🎉

However, re-renders on “add” and “delete” a country are still present. Let’s fix those as well.

Investigating “add” and “delete” re-renders

Let’s take a look at the TableBody code again.

<TableBody>
  {countries?.map(({ name }, index) => (
    <TableRow key={index}>
      <TableCell className="font-medium">
        <Link href={`/country/${name.toLowerCase()}`}>
          {name}
        </Link>
      </TableCell>
      <TableCell className="text-right">
        <Button
          onClick={() => onDelete(name)}
          variant="outline"
        >
          Delete
        </Button>
      </TableCell>
    </TableRow>
  ))}
</TableBody>

This entire thing re-renders when I add or remove a country from the list. Let’s apply the same strategy again: what would I've done here if I wanted to memoize those components manually?

It’s a dynamic list, so I’d have to:

First, make sure that the “key” property matches the country, not the position in the array. index won’t do - if I remove a country from the beginning of the list, the index will change for every row below, which will force a re-render regardless of memoization. In real life, I’d have to introduce some sort of id for each country. For our simplified case, let’s just use name and make sure we’re not adding duplicate names - keys should be unique.

{
  countries?.map(({ name }) => (
    <TableRow key={name}>...</TableRow>
  ));
}

Second, wrap TableRow in React.memo. Easy.

const TableRowMemo = React.memo(TableRow);

Third, memoize the children of TableRow with useMemo:

{
  countries?.map(({ name }) => (
    <TableRow key={name}>
      ... // everything inside here needs to be memoized
      with useMemo
    </TableRow>
  ));
}

which is impossible since we’re inside render and inside an array: hooks can only be used at the top of the component outside of the render function.

To pull this off, we need to extract the entire TableRow with its content into a component:

const CountryRow = ({ name, onDelete }) => {
  return (
    <TableRow>
      <TableCell className="font-medium">
        <Link href={`/country/${name.toLowerCase()}`}>
          {name}
        </Link>
      </TableCell>
      <TableCell className="text-right">
        <Button
          onClick={() => onDelete(name)}
          variant="outline"
        >
          Delete
        </Button>
      </TableCell>
    </TableRow>
  );
};

pass data through props:

<TableBody>
  {countries?.map(({ name }) => (
    <CountryRow
      name={name}
      onDelete={onDelete}
      key={name}
    />
  ))}
</TableBody>

and wrap CountryRow in React.memo instead. onDelete is memoized correctly - we already fixed it.

I didn’t even need to implement that manual memoization. As soon as I extracted those rows into a component, the Compiler immediately picked them up, and re-renders stopped 🎉. 2 : 0 in the human-against-the-machine battle.

Interestingly enough, the Compiler is able to pick up everything inside the CountryRow component but not the component itself. If I remove manual memoization but keep the key and CountryRow change, cells and rows will stop re-rendering on add/delete, but the CountryRow component itself still re-renders.

At this point, I’m out of ideas on how to fix it with the Compiler, and it’s enough material for the article already, so I’ll just let it re-render. Everything inside is memoized, so it's not that huge of a deal.

So, what’s the verdict?

The Compiler performs amazingly on simple cases and simple components. Three hits out of three! However, real life is a bit more complicated.

In all three apps that I tried the Compiler on, it was able to fix only 1-2 cases of noticeable unnecessary re-renders out of 8-10 that I spotted.

However, with a bit of deductive thinking and guesswork, it looks like it’s possible to improve that result with minor code changes. Investigating those, however, is very non-trivial, requires a lot of creative thinking, and mastery of React algorithms and existing memoization techniques.

The changes I had to make in the existing code in order for the Compiler to behave:

extract mutate from the return value of the useMutation hook and use it in the code directly.
extract TableRow and everything inside into an isolated component.
change the “key” from index to name.

You can check out the code before and after and play with the app yourself.

As for the assumptions that I was investigating:

Does it “just work”? Technically, yep. You can just turn it on, and nothing seems to be broken. It won’t memoize everything correctly, though, despite showing it as memoized in React Dev Tools.

Can we forget about memo, useMemo, and useCallback after installing the Compiler? Absolutely not! At least not in its current state. In fact, you’ll need to know them even better than it’s needed now and develop a sixth sense for writing components optimized for the Compiler. Or just use them to debug the re-renders you want to fix.

That’s assuming we want to fix them, of course. I suspect what will happen is this: we'll all just turn on the Compiler when it’s production-ready. Seeing all those “memo ✨” in Dev Tools will give us a sense of security, so everyone will just relax about re-renders and focus on writing features. The fact that half of the re-renders are still there no one will notice, since most of the re-renders have a negligible effect on performance anyway.

And for cases where re-renders actually have a performance impact, it will be easier to fix them with composition techniques like moving state down, passing elements as children or props, or extracting data into Context with splitted providers or any external state management tool that allows memoized selectors. And once in a blue moon - manual React.memo and useCallback.

As for those visitors from the future, I’m pretty sure now that they are from a parallel universe. A marvelous place where React just happens to be written in something more structured than the notoriously flexible JavaScript, and the Compiler actually can solve 100% of the cases because of it.

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

React Compiler & React 19 - forget about memoization soon?

Nadia Makarevich — Wed, 13 Mar 2024 17:09:53 +0000

React 19 and the React Compiler, previously known as React Forget, have been dominating the React discussion over the past month. We're all losing our minds (in a good way) over the possibility of never having to think about memoization in React very, very soon. Is it true, though? Should we start forgetting about memo, useMemo, and useCallback in the coming months? And what actually changes when the React Compiler is released, and what should we learn and teach about React after that?

Let's take a look.

React 19 is NOT the React Compiler

Let's get the most important thing out of the way: memoization is not going anywhere soon, so don't unlearn it just yet. React 19 is not the React Compiler. The React team announced the Compiler in the same blog post where they announced the soon release of React 19, and everyone excitedly jumped to conclusions.

A tweet from a React team member, however, clarifies this confusion:

In React 19, we'll see a bunch of new features, but we'll have to wait a bit longer for the Compiler. It's not clear right now how long, but according to another tweet from a different React core team member, it might happen by the end of this year.

Personally, I'm skeptical of this timeline. If we look at the talk by the React team members that introduced the Compiler and its timeline, we're in the middle of the Compiler's journey:

The journed started in 2021, two years ago. Rolling out something as fundamental as this on a codebase as large as Meta is probably very complicated. So the jump from the middle of the timeline to the end might take another 2 years.

But who knows, maybe the React team will actually manage to release it this year. That would be good news. The current promise of the Compiler, mentioned in the video, is that we won't need to change any code for its adoption. It will Just Work ™️. If it's actually released by the end of the year, it's a very good indication that this is indeed the case, and the rest of us should be able to switch to it quickly and easily.

However, even if the Compiler is released this year, and it is indeed very easy to adopt with no downsides, it doesn't mean that we'll be able to forget about useCallback and memo right away. There will always be a "transition" period, where we first talk about the case of "if you already have the Compiler enabled", that slowly transitions to "in the rare case you haven't migrated to the Compiler yet" scenario.

The mental transition from class components to functional components with hooks took, I think, at least 3 years (starting from 2018) - when all the courses, docs, and blogs caught up, most people migrated to the React version with hooks, and we started talking about functional components and hooks as a default. And even today, 6 years later, there are still plenty of class components lurking around here and there.

If we apply a similar timeline to the Compiler, that would mean that we'd need to hold onto the knowledge of what memo, useMemo and useCallback are for at least the next three years. Less, if you're lucky enough to work in a modern codebase that can migrate to the Compiler as soon as it's released. More, if you're a React teacher or work in a large codebase that is slower to migrate with plenty of legacy code.

What changes with the React Compiler

So what exactly is changing? The simplified answer is - everything will now be memoized. The React Compiler will be a Babel plugin that converts our typical React code into code where every hook dependency, props on components, and components themselves are memoized. Essentially, this code:

const Component = () => {
  const onSubmit = () => {};
  const onMount = () => {};

  useEffect(() => {
    onMount();
  }, [onMount]);

  return <Form onSubmit={onSubmit} />;
};

underneath will behave as if both onSubmit and onMount are wrapped in useCallback and Form is wrapped in React.memo:

const FormMemo = React.memo(Form);

const Component = () => {
  const onSubmit = useCallback(() => {}, []);
  const onMount = useCallback(() => {}, []);

  useEffect(() => {
    onMount();
  }, [onMount]);

  return <FormMemo onSubmit={onSubmit} />;
};

The Compiler doesn't convert them into exactly that code, of course, it's much more complicated and advanced than this. But it's a good mental model to wrap our heads around it. If you're curious about the exact details, I recommend watching this video from the React core team members who introduced the Compiler. And if you're slightly fuzzy on why we'd use useCallback and memo here at all, I'd recommend watching the first six videos of the Advanced React series on YouTube. They cover everything about re-renders and memoization. Alternatively, if you're more into reading, then read everything here.

For the way we're teaching and learning React, this transition means a few things.

If parent re-renders, child re-renders

Currently, if a Parent component re-renders, every component rendered inside will re-render as well.

// if Parent re-renders
const Parent = () => {
  // Child will also re-render
  return <Child />;
};

A lot of people currently believe that the Child component re-renders only if its props change. I like to call this The Big Re-renders myth. At the moment, this is not true. Props don't matter in the standard React behavior.

Funnily enough, it becomes true with the Compiler. Since everything is memoized under the hood, the current myth actually becomes the standard React behavior. In a few years, we're going to teach that a React component re-renders only if its state or props change, and whether the Parent re-rendered or not doesn't matter. Life is weird sometimes.

No more composition for performance

Currently, we have a few composition techniques like "moving state down" or "passing components as children" that can reduce re-renders. I usually recommend using them before messing around with useCallback and memo, since memoizing things in React properly is very, very hard.

For example, in this code:

const Component = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      <Button onClick={() => setIsOpen(true)}>
        open dialog
      </Button>
      {isOpen && <ModalDialog />}
      <VerySlowComponent />
    </>
  );
};

the VerySlowComponent re-renders every time the dialog opens, causing the dialog to open with a delay. If we encapsulate the state that opens the dialog in a component like this:

const ButtonWithDialog = () => {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <>
      <Button onClick={() => setIsOpen(true)}>
        open dialog
      </Button>
      {isOpen && <ModalDialog />}
    </>
  );
};

const Component = () => {
  return (
    <>
      <ButtonWithDialog />
      <VerySlowComponent />
    </>
  );
};

we essentially got rid of the unnecessary re-renders of the VerySlowComponent without memoizing anything.

When the compiler comes to life, these patterns will become unnecessary for performance. We'll probably still use them for composition and separation of concerns purposes. But there won't be a natural re-renders power anymore that forces us to split components into smaller components. Our components might become larger with no negative consequences.

No more useMemo/useCallback everywhere

Naturally, all the useMemo and useCallback that sometimes plague our code will be gone. That part excites me the most. No more tracking props through multiple levels of components just to memoize one onSubmit props callback. No more unreadable and undebuggable chains of useMemo and useCallback that all depend on each other and are impossible to understand. No more broken memoization just because children are not memoized and no one noticed.

Diffing & reconciliation

We might need to change how we explain diffing & reconciliation in React. The current simplified explanation is that when we "render" a component like this <Child />, we just create an Element of it. This element is an object of that shape:

{
  "type": ...,
  "props": ...,
  // other react stuff
}

where "type" is either a string or a reference to a Component.

In this code:

const Parent = () => {
  return <Child />;
};

when Parent re-renders, its function is triggered, and <Child /> object is re-created. React performs a shallow comparison of that object before and after re-render, and if its reference changes, then it's an indication for React that it needs to do a full diffing on that sub-tree.

Currently, this is the reason why the <Child /> component always re-renders, even if it doesn't have any props. The result of <Child /> (which is a syntax sugar for React.createElement function call) is an object that is always re-created, which means it can't pass the shallow comparison check.

With the React Compiler, the concepts of Elements, diffing, and reconciliation remain the same, so that's good. But it seems that <Child /> will now return a memoized object if its props haven't changed. So, actually, the end result of the Compiler is more of an equivalent of everything being wrapped in useMemo, even the Elements.

const Parent = () => {
  const child = useMemo(() => <Child />, []);
  return child;
};

But this is just me making assumptions from the limited publicly available resources, so I might be slightly wrong here. In any case, it's just an implementation detail that doesn't really matter for our production code.

Everything else stays pretty much the same as it is right now. Creating components inside other components will still be a massive anti-pattern. We'll still use the "key" attribute to identify elements or reset the state. Context is still going to be a pain to deal with. And everything about data fetching or error handling is not even part of the conversation.

But anyway, I can't wait for the Compiler's release. It seems like a massive improvement to our React life. Even if I have to re-write half of my articles and re-do half of my YouTube videos because of it 😅

Originally published at https://www.developerway.com. The website has more articles like this 😉

Take a look at the Advanced React book to take your React knowledge to the next level.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

React useTransition: performance game changer or...?

Nadia Makarevich — Mon, 23 Oct 2023 09:17:00 +0000

Let's implement a slow state update
Concurrent Rendering and useTransition for slow state updates
The dark side of useTransition and re-renders
How to use useTransition, then?
What about useDeferredValue?
Can I use useTransition for debouncing?

Unless you've lived under a rock for the last two years, you've probably heard the magic words "concurrent rendering" here and there. React was rewritten from scratch to support it, it's an entirely new architecture that gives us control over transitions through useTransition and useDeferredValue hooks, and it's supposed to be a game changer for the performance of our UI interactions. Even Vercel is improving their performance with transitions.

But is it truly a game changer? No caveats, for real? Can we use these transitions everywhere? What are they to begin with, and why do we need them? Let's investigate together and find out.

Let's implement a slow state update

First, let's implement something real with a performance problem. In the docs, they use the "tabs" component as an example where useTransition is useful, so let's implement exactly that. No copy-pasting, let's do it from scratch!

We'll have an App component that renders three tabs (Issues, Projects, and Reports) and conditionally renders the content of those tabs - the list of the latest issues, projects, and reports for our mini-competitor to Jira and Linear. The App will hold the state that switches between the tabs and renders the correct component. Easy-peasy so far:

export default function App() {
  const [tab, setTab] = useState('issues');

  return (
    <div className="container">
      <div className="tabs">
        <TabButton
          onClick={() => setTab('issues')}
          name="Issues"
        />
        <TabButton
          onClick={() => setTab('projects')}
          name="Projects"
        />
        <TabButton
          onClick={() => setTab('reports')}
          name="Reports"
        />
      </div>
      <div className="content">
        {tab === 'issues' && <Issues />}
        {tab === 'projects' && <Projects />}
        {tab === 'reports' && <Reports />}
      </div>
    </div>
  );
}

Now, the problem that transitions should help with: what if one of the pages is very heavy and slow to render? Let's say the Projects page renders a list of 100 recent projects, and the components in that list are very heavy and take something like 10ms to mount each. 100 items is not unreasonable, in theory. And although 10ms per component is a bit of a stretch, it could still happen, especially on a slow laptop. As a result, it will take 1 second to mount the Projects page.

Play around with the implemented code example here:

See how it takes forever to render the Projects page when you click the "projects" button? Now try to navigate quickly between those tabs. If I try to navigate from Issues to Projects and then immediately to Reports, I can't do that: the interface is not responsive. This is not exactly the best user experience: even if the Projects page is supposed to be that heavy and I can't optimize it now, the least I should do for the users is not to block the page from other interactions.

This is happening because a state update, despite popular belief, is not asynchronous. The triggering of it usually is: we do it asynchronously from various callbacks as a response to user interactions. But once the state update is triggered, React will very synchronously work on calculating all the necessary updates that need to be done, re-render all components that need to be rendered, commit those changes to the DOM so that they can appear on the screen, and only then let the browser go and take notice of what was happening while it was busy.

If we click a tab button during that, the state update from the click will be put in a queue of tasks and will be executed after the main task (the slow state update) is done. You can see this behavior in the console output of the slow example: all re-renders that you trigger via clicking the tabs will be logged, even if the screen was frozen at the time. Tasks and the queue of tasks is how JavaScript is processed by the browser. If you're not exactly sure how it works, I wrote a simple overview of them in this article: Say no to "flickering" UI: useLayoutEffect, painting and browsers story with a few more links at the bottom.

Concurrent Rendering and useTransition for slow state updates

The fact that a typical state update blocks the main task is what Concurrent Rendering aims to combat. With it, we can explicitly mark some state updates and the re-rendering caused by them as "non-critical". As a result, React will calculate these updates in the "background" instead of blocking the main task. If something "critical" happens (i.e., a normal state update), React will pause its "background" rendering, execute the critical update, and then either return to the previous task or abandon it completely and start a new one.

"Background" is just a useful mental model here, of course: JavaScript is single-threaded. React will just periodically check the main queue while it's busy with the "background" task. If something new appears in the queue, it will take priority over the "background" work.

But enough words, let's return to writing code. In theory, our situation with one of the tabs being very slow and blocking user interactions is exactly what concurrent rendering can help with. All we need to do is mark the rendering of the Projects page as "non-critical".

We can do this with the useTransition hook. It returns a "loading" boolean as the first argument and a function as the second. Inside that function, we'll call our setTab("projects"), and from that point on, that state update will be calculated in the "background" without blocking the page. Additionally, we can use the isPending boolean to add a loading state while we're waiting for that update to finish. To indicate to the user that something is happening.

Just three simple additions to the previous code, as simple as this:

export default function App() {
  const [tab, setTab] = useState('issues');

  // add the useTransition hook
  const [isPending, startTransition] = useTransition();

  return (
    <div className="container">
      <div className="tabs">
        ...
        <TabButton
          // indicate that the content is loading
          isLoading={isPending}
          onClick={() => {
            // call setTab inside a function
            // that is passed to startTransition
            startTransition(() => {
              setTab('projects');
            });
          }}
          name="Projects"
        />
        ...
      </div>
      ...
    </div>
  );
}

And look how cool this is:

When I click on the "Projects" tab button, the loading indicator shows up, and if I click on "Reports," I'm navigated there immediately. No more frozen interface, total magic!

The dark side of useTransition and re-renders

Okay, now that the navigation to the Projects page and back is fixed, let's take it a bit further. In real life, any of these tabs could potentially be heavy. Especially the Reports page. I imagine it will have a bunch of very heavy charts there. Why not anticipate this in advance, mark transitions between all of these tabs as non-critical, and update the state inside startTransition for all of them?

All I need to do is abstract that transition into a function:

const onTabClick = (tab) => {
  startTransition(() => {
    setTab(tab);
  });
};

And then use this function on all the buttons instead of setting the state directly:

<div className="tabs">
  <TabButton
    onClick={() => onTabClick('issues')}
    name="Issues"
  />
  <TabButton
    onClick={() => onTabClick('projects')}
    name="Projects"
  />
  <TabButton
    onClick={() => onTabClick('reports')}
    name="Reports"
  />
</div>

That's it, all state updates originating from these buttons will now be marked as "non-critical," and if both the Reports and Projects pages happen to be heavy, their rendering won't block the UI.

If we play around with the live example below, we'll see that…

I just made the page worse…

If I navigate to the Projects page and then try to navigate away from it either to Issues or Reports, it doesn't happen instantaneously anymore! I haven't changed anything on those pages, they both render just a string at the moment, but both of them behave as if they are heavy. What's going on?

The problem here is that if I wrap the state update in a transition, React doesn't just trigger the state update on the "background". It's actually a two-step process. First, an immediate "critical" re-render with the old state is triggered, and the boolean isPending that we extract from useTransition hook moves from false to true. The fact that I'm able to use it in the render output should've been a big clue. Only after that critical "traditional" re-render has finished, will React start with the non-critical state update.

In short, useTransition causes two re-renders instead of one. As a result, we see the behavior as in the example above. If I'm on the Projects page and click on the Issues tab, first, the initial re-render is triggered with tab state still being "projects". The very heavy Projects component blocks the main task for 1 second while it re-renders. Only after this is done will the non-critical state update from "projects" to "issues" be scheduled and executed.

How to use useTransition, then?

Memoization to everything

In order to fix the performance degradation from the above, we need to make sure that the additional first re-render is as lightweight as possible. Typically, it would mean that we need to memoize everything that can slow it down:

all heavy components should be wrapped in React.memo, with their props memoized with useMemo and useCallback
all heavy operations are memoized with useMemo
isPending is not passed as a prop or dependency to anything from the above

In our case, just simply wrapping our page components should do it:

const IssuesMemo = React.memo(Issues);
const ProjectsMemo = React.memo(Projects);
const ReportsMemo = React.memo(Reports);

They don't have any props, so we can just render them:

<div className="content">
  {tab === 'issues' && <IssuesMemo />}
  {tab === 'projects' && <ProjectsMemo />}
  {tab === 'reports' && <ReportsMemo />}
</div>

And voila, the problem is fixed, the heavy Projects page re-render doesn't block clicking on tabs anymore:

But this just shows that useTransition is definitely not a tool for everyday use: one small mistake in memoization, and you're making your app visibly worse than it was before useTransition. And doing memoization properly is actually quite hard. For example, can you say, off the top of your head, whether IssuesMemo will re-render here if the App re-renders because of the initial transition?

const ListMemo = React.memo(List);
const IssuesMemo = React.memo(Issues);

const App = () => {
  // if startTransition is triggered, will IssuesMemo re-render?
  const [isPending, startTransition] = useTransition();

  return (
    ...
    <IssuesMemo>
      <ListMemo />
    </IssuesMemo>
  )
}

The answer here is - yep, it will. Re-renders all the way! Issues are not memoized properly. If you're not sure why, here is the video for you: https://youtu.be/G7RNVYaRS3E. It explains what is happening, why, and how to fix it.

Transition from nothing to heavy

Another way to make sure that this additional initial re-render is as lightweight as possible is to use useTransition only when transitioning from "nothing" to "very heavy stuff". A typical example of that might be data fetching and putting that data into the state afterward. I.e. this:

const App = () => {
  const [data, setData] = useState();

  useEffect(() => {
    fetch('/some-url').then((result) => {
      // lots of data
      setData(result);
    })
  }, [])

  if (!data) return 'loading'

  return ... // render that lots of data when available
}

In this case, if there is no data, we just return a loading state, which is unlikely to be heavy. So if we wrap that setData in startTransition, the initial re-render caused by this won't be bad: it will re-render it with the empty state and loading indicator.

What about useDeferredValue?

There is another hook that allows us to tap into the power of concurrent rendering: useDeferredValue. It works similarly to useTransition, allowing us to mark some updates as non-critical and move them to the "background". It's usually recommended for use when you don't have access to the state update function. When the value is coming from props, for example.

In our case, we would use it if we extract our tabs' content components into their own component and pass the active tab as a prop:

const TabContent = ({ tab }) => {
  // mark the "tab" value as non-critical
  const tabDeffered = useDeferredValue(tab);

  return (
    <>
      {tabDeffered === 'issues' && <Issues />}
      {tabDeffered === 'projects' && <Projects />}
      {tabDeffered === 'reports' && <Reports />}
    </>
  );
};

However, the problem of double rendering is present here as well. Check it out in the implementation below.

So the solution here will be exactly the same as for useTransition. Mark updates as non-critical only if:

everything that is affected is memoized;
or if we're transitioning from "nothing" to "heavy", and never in the opposite direction;

Can I use useTransition for debouncing?

Another use case that sometimes shows up here and there for useTransition is debouncing. When we're typing something fast in an input field, we don't want to send requests to the backend on every keystroke - it might crash our server. Instead, we want to introduce a bit of delay, so that only the full text is sent.

Normally, we'd do it with something like the debounce function from lodash (or equivalent):

function App() {
  const [valueDebounced, setValueDebounced] = useState('');

  const onChangeDebounced = debounce((e) => {
    setValueDebounced(e.target.value);
  }, 300);

  useEffect(() => {
    console.log('Value debounced: ', valueDebounced);
  }, [valueDebounced]);

  return (
    <>
      <input type="text" onChange={onChangeDebounced} />
    </>
  );
}

The onChange callback is debounced here, so setValueDebounced is only triggered 300ms after I stop typing in the input field.

What if instead of the external library, I use useTransition? Seems reasonable enough: setting state inside transitions is interruptible by definition, that's the whole point of it. Will something like this work?

function App() {
  const [value, setValue] = useState('');
  const [isPending, startTransition] = useTransition();

  const onChange = (e) => {
    startTransition(() => {
      setValue(e.target.value);
    });
  };

  useEffect(() => {
    console.log('Value: ', value);
  }, [value]);

  return (
    <>
      <input type="text" onChange={onChange} />
    </>
  );
}

The answer is: nope, it won't. Or, to be precise, the debouncing effect won't happen in this example. React is just too fast, it's able to calculate and commit the "background" value between keystrokes. We'll see every value change in the console output in this example.

You can compare actual debouncing and the useTransition attempt here:

That is all for today. Hope it's a bit more clear now what Concurrent Rendering is, what hooks related to it are, and how to use them.

If you are to remember just one single thing from the article, then it's this: concurrent rendering hooks cause double re-renders. So, never use them for all state updates. Their use case is very specific and requires a very deep understanding of the React lifecycle, re-renders, and memoization.

As for me, I probably am not going to use useTransition or useDeferredValue any time soon. There are too many things to remember to get it right when we're talking about performance. The cost of mistakes is too high: the last thing that I need is to accidentally make performance worse. And for debouncing, it's just too unpredictable. I think I prefer the "old-school" way of doing it.

👉🏼 By the way, did you know that I wrote a book about advanced React patterns? It's called Advanced React, and it's a must-read for any React developer 😉.

Originally published at https://www.developerway.com. The website has more articles like this 😉

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

Fantastic closures and how to find them in React

Nadia Makarevich — Thu, 17 Aug 2023 09:40:53 +0000

This article is available in video format. Fewer details, but nice animations and voice instead of letters.

Also, this article is part of the "Advanced React" book. If you like it, you might like the book as well 😉

Table of content

The problem
JavaScript, scope, and closures
The stale closure problem
Stale closures in React: useCallback
Stale closures in React: Refs
Stale closures in React: React.memo
Escaping the closure trap with Refs

Closures in JavaScript must be one of the most terrifying features of the language. Even the omniscient ChatGPT will tell you that. It’s also probably one of the most hidden language concepts. We use it every time we write any React code, most of the time without even realizing it. But there is no getting away from them in the end: if we want to write complex and performant React apps, we have to know closures.

So let’s dive into yet another code mystery, and in the process learn:

What closures are, how they appear, and why we need them.
What a stale closure is, and why they occur.
What the common scenarios in React are that cause stale closures, and how to fight them.

Warning: if you've never dealt with closures in React, this article might make your brain explode. Make sure to have enough chocolate with you to stimulate brain cells while you're reading this.

The problem

Imagine you're implementing a form with a few input fields. One of the fields is a very heavy component from some external library. You don't have access to its internals, so you can't fix its performance problems. But you really need it in your form, so you decide to wrap it in React.memo, to minimize its re-renders when the state in your form changes. Something like this:

const HeavyComponentMemo = React.memo(HeavyComponent);

const Form = () => {
  const [value, setValue] = useState();

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
      />
      <HeavyComponentMemo />
    </>
  );
};

So far, so good. This Heavy component accepts just one string prop, let's say title, and an onClick callback. This one is triggered when you click a "done" button inside that component. And you want to submit your form data when this click happens. Also easy enough: just pass the title and onClick props to it.

const HeavyComponentMemo = React.memo(HeavyComponent);

const Form = () => {
  const [value, setValue] = useState();

  const onClick = () => {
    // submit our form data here
    console.log(value);
  };

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
      />
      <HeavyComponentMemo
        title="Welcome to the form"
        onClick={onClick}
      />
    </>
  );
};

And now you'll face a dilemma. As we know, every prop on a component wrapped in React.memo needs to be either a primitive value or persistent between re-renders. Otherwise, memoization won't work. So technically, we need to wrap our onClick in useCallback:

const onClick = useCallback(() => {
  // submit data here
}, []);

But also, we know that the useCallback hook should have all dependencies declared in its dependencies array. So if we want to submit our form data inside, we have to declare that data as a dependency:

const onClick = useCallback(() => {
  // submit data here
  console.log(value);

  // adding value to the dependency
}, [value]);

And here's the dilemma: even though our onClick is memoized, it still changes every time someone types in our input. So our performance optimization is useless.

Okay, fair enough, let's look for other solutions. React.memo has a thing called comparison function. It allows us more granular control over props comparison in React.memo. Normally, React compares all "before" props with all "after" props by itself. If we provide this function, it will rely on its return result instead. If it returns true, then React will know that props are the same, and the component shouldn't be re-rendered. Sounds exactly what we need.

We only have one prop that we care about updating there, our title, so it's not going to be that complicated:

const HeavyComponentMemo = React.memo(
  HeavyComponent,
  (before, after) => {
    return before.title === after.title;
  },
);

The code for the entire form will then look something like this:

const HeavyComponentMemo = React.memo(
  HeavyComponent,
  (before, after) => {
    return before.title === after.title;
  },
);

const Form = () => {
  const [value, setValue] = useState();

  const onClick = () => {
    // submit our form data here
    console.log(value);
  };

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
      />
      <HeavyComponentMemo
        title="Welcome to the form"
        onClick={onClick}
      />
    </>
  );
};

And it worked! We type something in the input, the heavy component doesn't re-render, and performance doesn't suffer.

Except for one tiny problem: it doesn't actually work. If you type something in the input and then press that button, the value that we log in onClick is undefined. But it can't be undefined, the input works as expected, and if I add console.log outside of onClick it logs it correctly. Just not inside onClick.

// those one logs it correctly
console.log(value);

const onClick = () => {
  // this is always undefined
  console.log(value);
};

You can play around with the full example here:

What's going on?

This is known as the "stale closure" problem. And in order to fix it, we first need to dig a bit into probably the most feared topic in JavaScript: closures and how they work.

JavaScript, scope, and closures

Let's start with functions and variables. What happens when we declare a function in JavaScript, either via normal declaration or via arrow function?

function something() {
  //
}
const something = () => {};

By doing that, we created a local scope: an area in our code where variables declared inside won't be visible from the outside.

const something = () => {
  const value = 'text';
};

console.log(value); // not going to work, "value" is local to "something" function

This happens every time we create a function. A function created inside another function will have its own local scope, invisible to the function outside.

const something = () => {
  const inside = () => {
    const value = 'text';
  };

  console.log(value); // not going to work, "value" is local to "inside" function
};

In the opposite direction, however, it's an open road. The inner-most function will "see" all the variables declared outside.

const something = () => {
  const value = 'text';

  const inside = () => {
    // perfectly fine, value is available here
    console.log(value);
  };
};

This is achieved by creating what is known as "closure". The function inside "closes" over all the data from the outside. It's essentially a snapshot of all the "outside" data frozen in time stored separately in memory.

If instead of creating that value inside the something function, I pass it as an argument and return the inside function:

const something = (value) => {
  const inside = () => {
    // perfectly fine, value is available here
    console.log(value);
  };

  return inside;
};

We'll get this behavior:

const first = something('first');
const second = something('second');

first(); // logs "first"
second(); // logs "second"

We call our something function with the value "first" and assign the result to a variable. The result is a reference to a function declared inside. A closure is formed. From now on, as long as the first variable that holds that reference exists, the value "first" that we passed to it is frozen, and the inside function will have access to it.

The same story with the second call: we pass a different value, a closure is formed, and the function returned will forever have access to that variable.

This is true for any variable declared locally inside the something function:

const something = (value) => {
  const r = Math.random();

  const inside = () => {
    // ...
  };

  return inside;
};

const first = something('first');
const second = something('second');

first(); // logs random number
second(); // logs another random number

It's like taking a photograph of some dynamic scene: as soon as you press the button, the entire scene is "frozen" in the picture forever. The next press of the button will not change anything in the previously taken picture.

In React, we're creating closures all the time without even realizing it. Every single callback function declared inside a component is a closure:

const Component = () => {
  const onClick = () => {
    // closure!
  };

  return <button onClick={onClick} />;
};

Everything in useEffect or useCallback hook is a closure:

const Component = () => {
  const onClick = useCallback(() => {
    // closure!
  });

  useEffect(() => {
    // closure!
  });
};

All of them will have access to state, props, and local variables declared in the component:

const Component = () => {
  const [state, setState] = useState();

  const onClick = useCallback(() => {
    // perfectly fine
    console.log(state);
  });

  useEffect(() => {
    // perfectly fine
    console.log(state);
  });
};

Every single function inside a component is a closure since a component itself is just a function.

The stale closure problem

But all of the above, although slightly unusual if you're coming from a language that doesn't have closures, is still relatively straightforward. You create a few functions a few times, and it becomes natural. It's even unnecessary to understand the concept of "closure" to write apps in React for years.

So what is the problem, then? Why are closures one of the most terrifying things in JavaScript and a source of pain for so many developers?

It's because closures live for as long as a reference to the function that caused them exists. And the reference to a function is just a value that can be assigned to anything. Let's twist our brains a bit. Here's our function from above, that returns a perfectly innocent closure:

const something = (value) => {
  const inside = () => {
    console.log(value);
  };

  return inside;
};

But the inside function is re-created there with every something call. What will happen if I decide to fight it and cache it? Something like this:

const cache = {};

const something = (value) => {
  if (!cache.current) {
    cache.current = () => {
      console.log(value);
    };
  }

  return cache.current;
};

On the surface, the code seems harmless. We just created an external variable named cache and assigned our inside function to the cache.current property. Now, instead of this function being re-created every time, we just return the already saved value.

However, if we try to call it a few times, we'll see a weird thing:

const first = something('first');
const second = something('second');
const third = something('third');

first(); // logs "first"
second(); // logs "first"
third(); // logs "first"

No matter how many times we call the something function with different arguments, the logged value is always the first one!

We just created what is known as the "stale closure". Every closure is frozen at the point when it's created. When we first called the something function, we created a closure that has "first" in the value variable. And then, we saved it in an object that sits outside of the something function.

When we call the something function the next time, instead of creating a new function with a new closure, we return the one that we created before. The one that was frozen with the "first" variable forever.

In order to fix this behavior, we'd want to re-create the function and its closure every time the value changes. Something like this:

const cache = {};
let prevValue;

const something = (value) => {
  // check whether the value has changed
  if (!cache.current || value !== prevValue) {
    cache.current = () => {
      console.log(value);
    };
  }

  // refresh it
  prevValue = value;
  return cache.current;
};

Save the value in a variable so that we can compare the next value with the previous one. And then refresh the cache.current closure if the variable has changed.

Now it will be logging variables correctly, and if we compare functions with the same value, that comparison will return true:

const first = something('first');
const anotherFirst = something('first');
const second = something('second');

first(); // logs "first"
second(); // logs "second"
console.log(first === anotherFirst); // will be true

Play around with the code here:

Stale closures in React: useCallback

We just implemented almost exactly what the useCallback hook does for us! Every time we use useCallback, we create a closure, and the function that we pass to it is cached:

// that inline function is cached exactly as in the section before
const onClick = useCallback(() => {}, []);

If we need access to state or props inside this function, we need to add them to the dependencies array:

const Component = () => {
  const [state, setState] = useState();

  const onClick = useCallback(() => {
    // access to state inside
    console.log(state);

    // need to add this to the dependencies array
  }, [state]);
};

This dependencies array is what makes React refresh that cached closure, exactly as we did when we compared value !== prevValue. If I forget about that array, our closure becomes stale:

const Component = () => {
  const [state, setState] = useState();

  const onClick = useCallback(() => {
    // state will always be the initial state value here
    // the closure is never refreshed
    console.log(state);

    // forgot about dependencies
  }, []);
};

And every time I trigger that callback, all that will be logged is undefined.

Play around with the code here:

Stale closures in React: Refs

The second most common way to introduce the stale closure problem, after useCallback and useMemo hooks, is Refs.

What will happen if I try to use Ref for that onClick callback instead of useCallback hook? It's sometimes what the articles on the internet recommend doing to memoize props on components. On the surface, it does look simpler: just pass a function to useRef and access it through ref.current. No dependencies, no worries.

const Component = () => {
  const ref = useRef(() => {
    // click handler
  });

  // ref.current stores the function and is stable between re-renders
  return <HeavyComponent onClick={ref.current} />;
};

However. Every function inside our component will form a closure, including the function that we pass to useRef. Our ref will be initialized only once when it's created and never updated by itself. It's basically the logic that we created at the beginning. Only instead of value, we pass the function that we want to preserve. Something like this:

const ref = {};

const useRef = (callback) => {
  if (!ref.current) {
    ref.current = callback;
  }

  return ref.current;
};

So, in this case, the closure that was formed at the very beginning, when the component was just mounted, will be preserved and never refreshed. When we try to access the state or props inside that function stored in Ref, we'll only get their initial values:

const Component = ({ someProp }) => {
  const [state, setState] = useState();

  const ref = useRef(() => {
    // both of them will be stale and will never change
    console.log(someProp);
    console.log(state);
  });
};

To fix this, we need to ensure that we update that ref value every time something that we try to access inside changes. Essentially, we need to implement what the dependencies array functionality does for the useCallback hook.

const Component = ({ someProp }) => {
  // initialize ref - creates closure!
  const ref = useRef(() => {
    // both of them will be stale and will never change
    console.log(someProp);
    console.log(state);
  });

  useEffect(() => {
    // update the closure when state or props change
    ref.current = () => {
      console.log(someProp);
      console.log(state);
    };
  }, [state, someProp]);
};

Play around with the code here:

Stale closures in React: React.memo

And finally, we're back to the beginning of the article and the mystery that initiated all this. Let's take a look at the problematic code again:

const HeavyComponentMemo = React.memo(
  HeavyComponent,
  (before, after) => {
    return before.title === after.title;
  },
);

const Form = () => {
  const [value, setValue] = useState();

  const onClick = () => {
    // submit our form data here
    console.log(value);
  };

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
      />
      <HeavyComponentMemo
        title="Welcome to the form"
        onClick={onClick}
      />
    </>
  );
};

Every time we click on the button, we log "undefined". Our value inside onClick is never updated. Can you tell why now?

It's a stale closure again, of course. When we create onClick, the closure is first formed with the default state value, i.e., "undefined". We pass that closure to our memoized component, along with the title prop. Inside the comparison function, we compare only the title. It never changes, it's just a string. The comparison function always returns true, HeavyComponent is never updated, and as a result, it holds the reference to the very first onClick closure, with the frozen "undefined" value.

Now that we know the problem, how do we fix it? Easier said than done here…

Ideally, we should compare every prop in the comparison function, so we need to include onClick there:

(before, after) => {
  return (
    before.title === after.title &&
    before.onClick === after.onClick
  );
};

However, in this case, it would mean we're just reimplementing the React default behavior and doing exactly what React.memo without the comparison function does. So we can just ditch it and leave it only as React.memo(HeavyComponent).

But doing that means that we need to wrap our onClick in useCallback. But it depends on the state, so it will change with every keystroke. We're back to square one: our heavy component will re-render on every state change, exactly what we tried to avoid.

We could play around with composition and try to extract and isolate either state or HeavyComponent. But it won't be easy: input and HeavyComponent both depend on that state.

We can try many other things. But we don't have to do any heavy refactorings to escape that closures trap. There is one cool trick that can help us here.

Escaping the closure trap with Refs

This trick is absolutely mind-blowing: it's very simple, but it can forever change how you memoize functions in React. Or maybe not... In any case, it might be useful, so let's dive into it.

Let's get rid of the comparison function in our React.memo and onClick implementation for now. Just a pure component with state and memoized HeavyComponent:

const HeavyComponentMemo = React.memo(HeavyComponent);

const Form = () => {
  const [value, setValue] = useState();

  return (
    <>
        <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
        <HeavyComponentMemo title="Welcome to the form" onClick={...} />
    </>
  );
}

Now we need to add an onClick function that is stable between re-renders but also has access to the latest state without re-creating itself.

We're going to store it in Ref, so let's add it. Empty for now:

const Form = () => {
  const [value, setValue] = useState();

  // adding an empty ref
  const ref = useRef();
};

In order for the function to have access to the latest state, it needs to be re-created with every re-render. There is no getting away from it, it's the nature of closures, nothing to do with React. We're supposed to modify Refs inside useEffect, not directly in render, so let's do that.

const Form = () => {
  const [value, setValue] = useState();

  // adding an empty ref
  const ref = useRef();

  useEffect(() => {
    // our callback that we want to trigger
    // with state
    ref.current = () => {
      console.log(value);
    };

    // no dependencies array!
  });
};

useEffect without the dependency array will be triggered on every re-render. Which is exactly what we want. So now in our ref.current we have a closure that is recreated with every re-render, so the state that is logged there is always the latest.

But we can't just pass that ref.current to the memoized component. That value will differ with every re-render, so memoization just won't work.

const Form = () => {
  const ref = useRef();

  useEffect(() => {
    ref.current = () => {
      console.log(value);
    };
  });

  return (
    <>
      {/* Can't do that, will break memoization */}
      <HeavyComponentMemo onClick={ref.current} />
    </>
  );
};

So instead, let's create a small empty function wrapped in useCallback with no dependencies for that.

const Form = () => {
  const ref = useRef();

  useEffect(() => {
    ref.current = () => {
      console.log(value);
    };
  });

  const onClick = useCallback(() => {
    // empty dependency! will never change
  }, []);

  return (
    <>
      {/* Now memoization will work, onClick never changes */}
      <HeavyComponentMemo onClick={onClick} />
    </>
  );
};

Now, memoization works perfectly - the onClick never changes. One problem, though: it does nothing.

And here's the magic trick: all we need to make it work is to call ref.current inside that memoized callback:

useEffect(() => {
  ref.current = () => {
    console.log(value);
  };
});

const onClick = useCallback(() => {
  // call the ref here
  ref.current();

  // still empty dependencies array!
}, []);

Notice how ref is not in the dependencies of the useCallback? It doesn't need to be. ref by itself never changes. It's just a reference to a mutable object that the useRef hook returns.

But when a closure freezes everything around it, it doesn't make objects immutable or frozen. Objects are stored in a different part of the memory, and multiple variables can contain references to exactly the same object.

const a = { value: 'one' };
// b is a different variable that references the same object
const b = a;

If I mutate the object through one of the references and then access it through another, the changes will be there:

a.value = 'two';

console.log(b.value); // will be "two"

In our case, even that doesn't happen: we have exactly the same reference inside useCallback and inside useEffect. So when we mutate the current property of the ref object inside useEffect, we can access that exact property inside our useCallback. This property happens to be a closure that captured the latest state data.

The full code will look like this:

const Form = () => {
  const [value, setValue] = useState();
  const ref = useRef();

  useEffect(() => {
    ref.current = () => {
      // will be latest
      console.log(value);
    };
  });

  const onClick = useCallback(() => {
    // will be latest
    ref.current?.();
  }, []);

  return (
    <>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
      />
      <HeavyComponentMemo
        title="Welcome closures"
        onClick={onClick}
      />
    </>
  );
};

Now, we have the best of both worlds: the heavy component is properly memoized and doesn't re-render with every state change. And the onClick callback on it has access to the latest data in the component without ruining memoization. We can safely send everything we need to the backend now!

Play around with the fixed example here:

Hopefully, all of this made sense, and closures are now easy-peasy for you. A few things to remember about closures, before you go:

Closures are formed every time a function is created inside another function.
Since React components are just functions, every function created inside forms a closure, including such hooks as useCallback and useRef.
When a function that forms a closure is called, all the data around it is "frozen", like a snapshot.
To update that data, we need to re-create the "closed" function. This is what dependencies of hooks like useCallback allow us to do.
If we miss a dependency, or don't refresh the closed function assigned to ref.current, the closure becomes "stale".
We can escape the "stale closure" trap in React by taking advantage of the fact that Ref is a mutable object. We can mutate ref.current outside of the stale closure, and then access it inside. Will be the latest data.

The video based on the material in this article is available below. It's less detailed but has nice animations and visuals, so it could be useful to solidify the knowledge.

This article is part of the "Advanced React" book. If you like it, you might like the book as well 😉

Originally published at https://www.developerway.com. The website has more articles like this.

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

Forem: Nadia Makarevich

Tailwind vs Linaria: Performance Investigation

Setting up the investigation

Why Linaria vs Tailwind: reasoning and initial assumptions

Why Linaria?

What's up with Tailwind?

What we're measuring

Measuring the change in assets

Measuring LCP in Client mode

Measuring LCP in SSR mode

Measuring INP

Results of the investigation

SSR Deep Dive for React Developers

Why no-JavaScript environments are so important

Server pre-rendering

The cost of server pre-rendering

Where to deploy?

Performance impact of having a server

Next.js on Vercel/Netlify

Pre-rendering the entire page on the server (SSR)

SSR can make initial load worse

SSR and hydration

Should I implement SSR like this?

SSR and frontend

Browser API and SSR

useEffect and SSR

Conditional SSR rendering is a big no

Third-party libraries

Static Site Generation (SSG)

[Boost]

Initial load performance for React developers: investigative deep dive

Nadia Makarevich ・ Jan 27

Initial load performance for React developers: investigative deep dive

Table of contents

Introducing initial load performance metrics

Overview of the performance DevTools

Setting up the project

Exploring the necessary DevTools

Exploring the Lighthouse panel

Exploring the Performance panel

Additional Exercise

Exploring different network conditions

Very slow server

Emulating different bandwidth and latency

Additional Exercise

The importance of CDN

Repeat Visit Performance

Controlling Browser Cache with Cache-Control Headers

Additional exercise

Additional exercise

Cache-Control And Modern Bundlers

Additional exercise

Do I really need to know all of this for my simple use case?

How React Compiler Performs on Real Code

The problem of re-renders and memoization in React

React Compiler 🚀 to the rescue

React Compiler on simple examples

React Compiler on the real app

Initial load performance and the React Compiler

Interactions performance and React Compiler

Measuring the first page

Measuring second page

Can React Compiler catch all re-renders?

Quick summary

Existential React questions and a perfect Modal Dialog

Step 1: Start with the simplest solution

Step 2: stop, ask questions and think

Step 3: solidify the Modal Dialog API

Step 4: performance and re-renders

Step 5: dealing with edge cases and accessibility

Step 6: final polish

A few more thoughts

Intro to CSS animations for React developers

Expandable search field with CSS transition

Improving hover and focus on buttons with CSS transition

Tabs: triggering transitions with React state change

Making cards larger on hover with transform and transition

Implementing sliding drawer with simple transition

Implementing sliding drawer with animation and keyframes

Implementing sliding drawer with react-transition-group