React Performance Patterns That Break Down in Long-Running Production Apps

Hey, everyone. I'm Himanshu, and today I want to talk about React performance patterns that break down in long-running production applications. These are bugs that I've noticed in my own work which did not show up in staging, which crossed code reviews, and which came up in A lot of times, these became bugs that were non-replicatable by us and would cause issues down the line. And that's the knowledge I'm going to discuss with you right now.

So these are five bugs, but these all share the same mental model. And I'll show a demo of all of these and we'll get through how these impact production applications and why. So there are five. There's the memory leak. There's tail closures. There's use callback, which cause tail closures. There's race conditions, and there's circular dependencies. So let's discuss the mental model first. This mental model is something that I would want all of you to take away. If there's one thing you take away from this session, make sure it's this. And what the mental model tells us is that every render is a snapshot in React.

Basically, every time a component renders, React takes a snapshot of all the states, the values, the handlers, everything. And they remain frozen in that point of time. What this means is, let's say you initialize an event listener or a function or a use callback or anything for that matter. It closes and it uses the terms and the values which were there at time of registering the function, not when it executes it. We'll get into examples and I'll explain what this thing means, but I'll make sure this is ingrained within us.

So let's get into the first one, the memory leak. Now, what does this mean? Well, a lot of times we use event listeners A lot of times we use event listeners, right? We have event listeners on clicks, we can have it on scroll, we can have it on mouse enter, a lot of things. A bug which often ends up getting missed is not having a clean-up. And this is something which I've seen a lot of engineers confidently and it very easily passes code reviews because it's such a minor thing that we end up missing. We focus on the major issues so much that this ends up passing.

And the reason happens is, in staging environments or in testing environments, we refresh the pages a lot. The event listeners get cleaned up as it is, but in production what I've noticed is people might have your app or your tab open for hours or days at times, right? And all these detached event listeners can keep adding up, causing memory issues. Eventually it leads to a slowdown of the app or random crashes, you get the point.

So here's a little more of it, right? So if you see out here, I have a component which I've mounted. It's a very simple code that I've written. So there's a component and I've simply added an event listener out here. I'll just show it to you. So there's an event listener on click which just logs value. So if you see any time I click I have the console out here and it logs. So anyway, let me show it. I click, it logs. I click, it logs. Seems fine, right?

Let's say I unmount it. Now I mount it again. You see now the active click listeners is two. So every time I click, there's two of the logs. And let's say I mount, I mount, mount, you know, a few times. Now if you see every single click it's logging five times. Now imagine this in a real-world scenario. You have an event listener on click or on hover, which maybe adds some CSS or opens modal, could be anything, right? Now oftentimes these actions of ours are idempotent. So it doesn't matter if the listener fires once or 10 times, the end result will be the same.

So it will not be caught that easily, unless you're modifying some states, right? But what ends up happening if you see out here, all these listeners, they'll stay in memory. Even if I go to another tab, come back, you see that it's still there because the app is running, right? Even if the component has unmounted. Imagine hundreds of these or thousands, they will slow down your system to an extent where it will need to crash. There are more times your component could mount or unmount to create the impact.

So let me reset the listeners for now. And how do we fix it? I mean, it's a pretty simple fix. Anytime you have a listener, you should have a cleanup, right? So most of the times we have these listeners and useEffects. So we should ensure that you always have a cleanup function written. UseEffects provides us with that, right? We can use this. And it's not just for event listeners. It's for a lot of other listeners as well. There could be some WebSocket connection that you've set up, or WebRTC-related connection. We've faced these, right? And that's what I wanted to share.

So can you see just one fix? And now if I unmount it, there's zero active listeners. I mount it again, there's one. Unmount zero. If I keep clicking, nothing happens. If I mount again, every click, I get just one. So the bug was just one line of code. The fix is just one line of code, but it impacts thousands, if not millions of users. Just one single line, right? And it causes random app clashes and it impacts the user experience. So that's something to keep in mind. So let me just reset the listeners, and let's move on to the next part, stale closures.

Now, this one is sneaky, because I've noticed in our use case as well, we had a component on which we had two different listeners. One was a click listener, and the other was the listener on key press, which would perform the same action, but they were spread apart. And because of which, they were calling the, let's say, primary action using two different functions. Happens a lot when you have a large code base, right? So what ended up happening is the mouse click, the listener for that, it was using values from a different location, and the enter key press was using from a different location, which is fine, right? They should be getting the same values, they'd call their own functions, perform their side effects, and then would perform the common action. But the issue that was there was on the key press, the value that was getting, it was reading from a state, and you should know, again, the same mental model. Whenever you define a listener or anything in React, it will capture the value of the states that exist at that particular point. Right? So when the listener was registered, it captured the values at that point. So when it executed, it ideally should have taken the latest values, but it didn't, right? It took the old values. And it was something that we didn't notice because the side effect to it was mine. But later on the line, when we realized, that's when we figured out that, okay, this can impact. The impact could be worse, right? Because you might have a lot of actions being performed on it, maybe some value count, or maybe some analytical data, and that will be corrupted, and you might not realize it. So let's see an example.

So here, if you see, I have just a button which increments a counter, and I have a listener added on enter. Let's say I increment it to 6 and I press enter. So you see, the enter key shortcut saw the value 0, but the actual state was 6. Why? I'll show you the code. It's pretty standard, right? I just have a state and use effect of a handler which on enter key press, would lock the value. Do you see the error? The error is out here in the dependencies, I do not have anything mentioned, right? It's an empty dependency array. So it basically means that this use effect will run only once when the component mounts. When the component mounts, the value of the state is 0. So no matter how many times I increment it, the value of state will change, but this function, the function that we define within use effect, it will always, always see 0, no matter what. What's the fix? There's a lot of ways we can fix it. One such way is simply using a ref, right? There's two ways, actually, many more to be honest, but a clean way that I figured is use a ref. So if you see, I've created a ref, right? And in use effect, I've just put a dependency on the state, whenever it changes, the value of the ref will change, right? So when you press enter, it will basically just take that value. Another option could be to change the dependency array and add the state out here, but the reason that it's not recommended here is that every single time the value of this state changes, the listener will be destroyed and a new listener will be created. That's a lot of extra work. Just use refs for this exact purpose. Let me show you now. Here we're doing the fixed code, that is this one. So let's say I increase it to six and I press enter, you see, it reads the correct value, it's as simple as that.

So we should know when to use states, when to use refs and whether or not our code is causing stale values, because a lot of times, it might be six functions deep or seven components deep. And while you shouldn't do props really much, but maybe you're using, you know, values from a state in different components and you expect them to work together, but things might break. But yeah, let's come to the third part, the use callback line. The reason I call this a lie is you're essentially lying to React if you're facing this issue. And I've seen this issue come up more times than I'd like to admit both, you know, when I've been coding it or someone in my team in various codebases, various places I've done it, right? I've seen it come across, not just in normal, you know, projects, but in production applications.

What happens is a lot of times when we write code, especially in the age of AI, you know, right? We use all these use callback, use memo and all of these were dependency arrays to optimize our applications. However, the recent versions of React, you know, and Nix handle a lot of this for us. But let's face it, most codebases still have not migrated to the latest versions, right? So what ends up happening is you might have done this yourself. We write code like this, you know, have some filters. When you click filter, you click fetch. Basically, it fetches the data. And for this function, you might have a simple use callback, right? Something like this, which would fetch data from the API.

And here in dependency array, if you notice out here also, we just have state switches of filter, which could change, right? Currently it's alpha, we can change it to beta, gamma, or delta. And this function would basically fetch the data out here. If you see we have an empty dependency array. What does that mean? It means that function will capture the value of the filter at the time it was registered, which is alpha. So even if you change it to beta, this function will not be recreated because we've told, but it's in a use callback to not recreate the function. And when should it recreate? Never. It's an empty dependency array, right? It will create on mount. That's the issue. Now, this is a very simplistic example, but oftentimes what happens is we use functions, which, you know, use a lot of different states, a lot of different sub functions, all of that.

And we put in a use callback. And in the dependency array, we put two or three dependencies which we feel are correct. React might give you a warning, or your IDE might give you a warning that you're missing some dependencies. But what we end up doing, we use ESLint, disable missing depths. That is wrong because the dependency array's sole task is for us to tell React that these are the values I'm using in the function. Any time a value changes, the function should recreate, not rerun. We get confused and think that we'll just skip the dependencies. That's wrong because you're going against the way React was designed to be used, causing many issues.

If your code does not work without you having to skip or miss some dependencies, you should rethink your code. In 99% of the cases, if you have missing dependencies in useCallbacks, memos, useEffects, your code is buggy. It's a silent bug. So, do revisit. Let's see the fixed version. All you have to do is add the filter to the dependencies. It's a simple fix. Now, when you call the data, it fetches with alpha. Change it to beta and call it. It's now called with beta. Change it to comma. It works. It's a simple mental model. Do not lie to React. Every render captures a snapshot of the values. Every function defined in a render captures the values at that point in time. Never lie to React. Do not miss dependencies.

And second, never lie to React. Do not miss dependencies. Now, let's come to my favorite one, the race condition. So, a lot of you might have faced this, right? We oftentimes have a ton of APIs running, you know, a ton of API calls happening from the front end. And every single time a user changes to some other window or some other tab or clicks a button, more API calls might be called. And the old ones are to be stocked. However, I've noticed when writing a lot of APIs, we miss on canceling them. So, I'll show you an example.

For instance, out here, we just opened out here. And if you see, it's written fetch A. These are three requests, A, B, and C. You can assume that, let's say, if you're in a CRM, right? And you've applied a filter. So, first filter could be, let's say, for a particular WhatsApp channel. Second filter could be for a particular mail channel. Third one could be, let's say, for some particular other channel, let's say, Instagram, right? Now, we cannot determine the time that the API response would take to respond, right?

Maybe it takes a minute, maybe it takes a second, maybe it takes five seconds, right? But we cannot guarantee that if I call A, then B, then C, the response will be in that order. If you see I've queried A, and I have got the response A. If I query B, I have got the response B. I query C, I get the response from C, right? It takes a second. But now what happens, let's say, if the user clicks on B, and then A, or A, then B, let's say.

So, user called A before it called, I went to B. You see what happened over here? What ended up happening, let me just showcase it again. So, let's say I go A, and then I go back to B. You see, I fired the request for A, then I fired the request for B. Now, the request for B, the response for B, came faster. So, that value got sent. And then the response from A came, which overloaded the value of B. So, according to the user, what happens, they've selected a filter B, but the data that they've gotten is for the filter A, which is wrong.

Why does this happen? Simply because we cannot guarantee the time it would take to respond. I'll show you the code, right? It's very simple user effect. We just do not have a cancellation. Here, we do have the dependencies correct as well, but how do we fix it? Well, anytime your dependency changes, basically, filter, and you know the value has to be called again. In that case, you should cancel the existing request. How do you do it? It's two options. I prefer the second one. I'll show the first one as well.

You can simply have a cancelled flag. So, cancelled is false. And any time your user effect is cleaning up, you can just set cancelled to true. And here we've just added a check that if it's not cancelled, then you call the API. Basically, what it does is anytime you click on a different filter, the old one will be cancelled. So, when you get a response for the old one, it is cancelled, so it will not send the data. Basically, we're ignoring the data. But there's a better way, that is using abort controllers. If you're not well aware about it, you can read about it. It will take five minutes of your time, but it will improve your code quality a lot.

How does that work? You just set up a new abort controller and you pass it in whatever framework you're using. Pretty much all of them support it, right? You pass the signal out. So, anytime you want to abort, or basically, your user effect is getting cleaned up, you just pass controller.abort, and it will take care of it.

So, I'll show you the updated one. Again, the same thing. I fetched B, then I fetched A. Works perfectly. See? I clicked B, I clicked A, but there is, in the middle part where it showed incorrect, that's because we're waiting for it. I did not put a load estate. So, simple fix, right?

Coming to the final thought, circular dependencies. Now, this is something I'll tell you I've had my fair share of cleaning circular dependencies at a point. Notice there were hundreds, right, which ended up happening. These do not cause issues that are very easily noticeable, but they do slow down your app. They might cause unpredicted behavior. They also increase build times, because tree shaking cannot happen.