React Concurrency, Explained

1,489 days! This is how much time passed between Dan Mobromov's first review of what back then was called Time Slicing and Direct18 release which finally made these capabilities available for everyone. In these 1,489 days, Time Slicing went through a bunch of rebrandings, several API changes, and today became known as concurrent rendering.

Now, concurrent rendering generally includes two features. Hooks like useTransition and useDefaultValue and improvements around suspense and hydration. There's also a third performance feature that Direct18 shipped, better batching of updates, but it's not part of concurrency.

So when I first tried working with these concurrent features, especially with stuff like useTransition, it sometimes really felt like magic in terms of how it optimizes the app. So today, I want to show you folks what actually happens in the app whenever you use the first, the most foundational performance feature, useTransition, and how Rack achieves this magic, which is actually not magic at all. So let's dive into useTransition, useDefaultValue hooks, and to show them, let me show you a slow app.

So this is a basic not-taking app. Oops! Oh, wait! Oh, no! I—I, hold on. Sorry. I— This. Yes. Ah! Yes, we're back. So this is a basic not-taking app, and it has a list of nodes which you can filter. And if you try to filter these nodes, the app will get slow. You can notice it if you look at this cube of ice that spins. It's a spinner that freezes when the app freezes, when the page freezes, and, well, spins when it's not frozen, kind of like opposite of ice.

If I try typing, if I try filtering nodes, if I try typing the F letter, for example, you can notice how the spinner freezes for a second or two. If I try typing more, you could see how the app just lags as I'm typing. So you can't really feel it, because I'm typing behind the keyboard. But you could see how I'm typing, and the app feels really, really slow. The UI updates, happens with the delay, and the app just freezes for a second or two.

So now, whenever I have a performance issue, what I like to do is I like to open DevTools Profiler, DevTools Performance, and try to record what's happening in the app with the performance pane. So in this case, if I click record, and try typing, and stop recording, I'll see that what's happening in the app is I have this huge 500ms spike of CPU activity, and if I zoom into that spike of CPU activity, I'll see that I have a single keydown event that takes 550ms to process, and underneath that event, there are a whole lot of React function calls.

So now, if I were to debug this a little deeper and try to figure out what's going on, I would see this. So here's what happens in the app. What happens is I'm typing into the text field, the filter inputs, that calls this set filter function, which is just a useState hook, that, in turn, changes the state in a bunch of components, and that causes React to render all these components one by one until it's done. And because we have a lot of components, a lot of node buttons, that takes a while. So this re-render is a stop-the-world operation. Nothing can happen until React is done. If a user tries to interact with the app in any way, they'll have to wait until the re-render is done. If re-rendering the app takes two seconds, the user will have to wait for two seconds. This is how React 17 works, React 16 works, even React 18 works out of the box. A pretty standard JavaScript blocking behavior.

Now, let's take a step back. We have a performance issue, right? I'm typing to the text field, and that text field goes to a list of nodes to re-render, and this re-render is blocking and expensive, which slows the app and slows the whole typing process. So my question to you, to you folks, if you were a developer of this app, and this app was using React 17, how would you try to solve this? There are multiple solutions here, what would you try? Sorry? De-balancing.

De-balancing, throttling, yes. Oh, it's really hard to hear from here. Virtualized DLS, yes, another great solution. Any other ideas? Good, so yeah, there are multiple things we could try here. We could try using React Memo if the components render unnecessarily. We could try optimizing the components themselves, maybe the components are expensive for some reason, we could try virtualizing the list to only render the items that are visible on the screen, we could try debalancing or throttling, and these are all great solutions and you can even combine them, but what React 18 does is it introduces another solution to the mix, making updates non-urgent.

What does this mean? So with React 17 and below, every update that happens in the app is considered urgent. If you click a button, React has to handle that update immediately. If you type into the filter input, React has to render the list of nodes immediately. With React 18, your update can now have a priority. Every update you make in the app is still by default urgent, but what React now also supports is non-urgent updates, and non-urgent updates almost magically don't block the no matter how long they take. Let's see how this works. Bear with me. I lost my mouse. Here's my mouse. Oh no, yes.

So, let's switch back to code. Let's switch back to the main mouse. It's kind of confusing, if I put my mouse here, or like this demonstration, it's also duplicated there, so I can never know where the mouse is. Anyway, so, let's look at the code. This is the code of the app that we have here. This is the code of this nodes list component that we have on the left. In the nodes list component, we have the filter inputs, and we have the list of buttons. So, here's the filter input that we have in the app UI, and here is the list of buttons. All this UI is controlled by the single filter state field. Whenever I type into the field, this filter field updates, and the UI re-enters. Now, this update, by default, is considered argent. To make an update non-argent, what I need to do is to use one of three new React performance APIs, React start transition, React use transition hook, or React use the first value hook. They're all pretty similar. They do more or less the same thing.

So, I'm going to focus only on the second one, use transition. And so, here's what I'm going to do. First, I'm going to go to the very top and import the use transition hook from React. Second, I'm going to call this use transition hook in the code, and the use transition hook returns two values. No, GitHub copilot, you are wrong. It returns the is pending flag, which indicates that transition is ongoing, and it returns the function, start transition, which lets you actually mark some updates non-urgent. Then, the third change that I'm going to make is, and bear with me, I'm going to take this piece of state, and I'm going to split it into two bits of state. Oh, no, wrong buttons. If you look at this filter, you will notice that it controls two parts of the UI, right? It controls the filter that we have here, and it controls the list of nodes that we have here. So the thing about this bit of state is that ... Or the thing about this UI is that one part of this UI is a part of the UI that we want to update immediately, urgently. It's the filter input. Like whenever the user is typing into the filter, we want to reflect the change immediately, we want to update it immediately. But the list of nodes can be filtered with a delay. It can be updated non-urgently. So what I'm going to do is I'm going to take this bit of state and I'm going to split it into two bits of state. One that's going to be updated urgently, and another one that's going to be updated non-urgently. So I'm going to clone the use state and call the first ... Let's call it setFilter. Sorry, let's call it filterInput and setFilterInput, because it's going to control the input. And the second one is going to control the list of nodes, so maybe I'll call it filterValue and setFilterValue. Now I'm going to take this filter input state and pass it here, and I'm going to take this filter value state and pass it farther down the code. Oh no, hold on, this, this, this. Oh yeah, and the one on the top. Paste here, paste here. Done. And now I also need to update these states, right? So before I was, I had like one set state hook. Now I'm going to have two, so I'm just going to value, okay, that was, that was a spoiler from GitHub quality. SetFilterValue. Value, yep.

So, and the closing bracket. So what we did here so far is we, we did, like, we did pretty much nothing. Like, the only change we did so far is we take, took this bit of state and we split it into two bits of state. And so, which is pretty, well, it doesn't, doesn't make any sense yet.

So like, if I try typing to the filter, you'll notice that, like, it's still, it's still slow. It's still lagging, right? I'm pressing F and the IceCube lag, like stuff's spinning for a second. But that's because both of these state updates are still urgent.

So what I'm going to do now is I'm going to make one last change. I'm going to take my setFilterValue hook and I'm going to mark it, setFilterValue call, and I'm going to mark it as non-urgent. And I'm going to do this by wrapping it with StartTransition. And so, look, the only change I made, I wrapped the filter state with StartTransition. And now if I try typing into the filter, you'll notice that the list of nodes still updates, but the app does not freeze at all, the ice cubes keep spinning uninterrupted the whole time. It's batterithmost.

I can type as much as I want and it updates perfectly. So it's like magic. It's so cool. So now could anyone guess how this works? How does React do this, do you know or are you guessing? Promise? No? Maybe in that direction. Go ahead. I would say it just queues it and whenever it's free it does something and then it spins again. But did you notice that the ice cubes kept spinning the whole time? When you do something, when you click on something immediately so whenever React dims it's able to do so, it will run that phase of code. Kinda yes, but... It's just a guess. Yeah, yeah, okay, yeah. Any other ideas? I'm sorry for live listeners this is probably the boring part. Go ahead, yeah. Is it sitting out? Sitting out? It's a part, but no. So the way this works is... Sorry, wrong slide. The way this works is given back control. So what React does it starts rendering the app, and then it gives back control to the browser after every frame. Let's see how this looks in DevTools. So, in DevTools, this was the old behavior, right? I pressed the keyboard button, and the main thread was blocked for 500 milliseconds. The React started rendering and React kept rendering for 500 milliseconds. So what React is going to do now, or what React is doing now is if I type any single letter, and then stop recording, and see what happens, I would still notice a single spike of the CPU activity, right, in the top. But if I zoom into that spike, I'll see that my key perceived when that happened when I typed the F letter, it takes now just 15 milliseconds, and here React performs the Argent update immediately, no matter when the click happens, because every known Argent updates will typically be blocking the main thread only for five or 10 milliseconds. This is how React 18's concurrent rendering and this is how it works under the hood. Now, let's talk about drawbacks because, of course, there's no free lunch. The first drawback is that known Argent updates take longer. React has to yield the control back to the browser all the time and that introduces some delays. So if I switch back to the browser, I'm not going to reproduce that now, but I just took this app and I made the recording with start transition and without start transition. So in the case without start transition, when I was recording it an hour ago, this key press event took 473 milliseconds to render, and it blocked the main thread for the whole time. When I added start transition, the main threads stopped being blocked, but the whole update, like rendering all the components took longer. It took it, can you see it? 582 milliseconds.

So 100 milliseconds longer. So this overhead, it's not constant, it depends how many components you're rendering, I don't know, et cetera. It's not like it's 100 milliseconds longer every time, or 20% longer, but what you see here is because Rect has to give the control back to the browser every time, the whole update finishes later. Maybe that's okay because it's marked as non-urgent, but that's a drawback to keep in mind.

The second drawback is this extra complexity does not come for free. To make concurrent rendering possible, Rect had to make its architecture much more complex. It introduced RectFiber, which by the way, the next talk on that stage is going to talk about. Go check it out. It introduced concurrent rendering checks. All this stuff takes a toll on the CPU, and in fact this is one of the reasons Vue and Preact straight refuse to implement anything similar to concurrent rendering. Both Vue and Preact believe that it's unlikely any real world apps will benefit from concurrent features. Like Marvin from Preact, for example, says, it's still up in the air whether concurrent mode is something that will benefit apps at all, even for React. Or Evan from Vue says, the demo Rect team showcased, it's so contrived that it will most likely never happen in the actual app. And I'm showing screenshots from 2019 and 2020, but based on Twitter conversations, nothing has changed since then.

Now, the React team, however, seems to play a long game and is explicit about it. I'm not sure if it's still on Twitter because that's where all the real documentation lives nowadays but Dan, for example, in this tweet says, this unlocks many abilities that weren't possible. Time slicing is just a nice bonus. And one of the things that the concurrent features will unlock is the upcoming off-screen API, which allows for rendering invisible UI parts in the background, and it does require concurrent rendering to work, to not block rendering when it's rendering, rendering, rendering. Anyway, there's another drawback slash pitfall. React concurrency does not help to optimize expensive components. If you look at the React's primary rendering loop again, you'll notice that should yield to host this function that checks whether React has to give the control back to the browser, it's only called after every render, right? So like the performing unit of work function, it takes one component. It starts rendering it. And then only once that rendering is complete should it yield to host checks whether React should give the control back to the browser. So if any single component takes, for example, not five but 500 milliseconds to render, the main thread will still be blocked for the full 500 milliseconds, even despite this update being marked as non-urgent. And this is the third drawback of React concurrency. Drawback slash pitfall. So to summarize, React concurrency is slower for non-urgent updates. It's more CPU expensive for all updates. It does not help with expensive components, but if you're willing to deal with all these drawbacks and pitfalls, you'll get this almost magical behavior of rendering something huge and not slowing the page at all. Is this a meme? Maybe this is a meme.

Thank you. Okay, so we have some questions. Yes. First of this, how can I know or judge that I need to use useTransition? What are some signals or signs that you should look for? So good question. I don't have an intuition about this yet to be clear. But I'm going to try to answer. If your app is slow, and if you see that it's like if you try to run a rectProfiler and you see that it's not because there's like some single expensive component, but a bunch of small ones, which is like pretty much how typical happens. And you know that like, you can delay some parts of the UI, then you would use it or actually a better transition. So if you're thinking of using throttling, or bouncing, try startTransition first, because it works pretty much in the same way but it's better because it does not delay anything. It does not delay rendering by like a second or two seconds. Nice.

Thank you. Why do updates give unexpected incomplete results when writing tests? Like, is there a scenario in here when you're doing automated tests and you expect something to happen on screen, maybe on tick? I have not... Yeah, I don't know. I guess like good tests, they typically wait for like an element to appear on screen. That's not going to affect these tests. Yeah, if there's tests that uses the timer then I guess that might affect them a little. Yeah, that's true.

Wait. Next one. Let's see. Too many questions. How are deprecated updates cancelled? So if you have multiple... OK, yeah. That's a great question. So Rack just cancels them. I don't remember the exact mechanics. But if I type F and Rack starts rendering this huge list of notes, and then 100 milliseconds later I type another letter, then Rack will just throw away the first render that's been on progress. It will start rendering the second render. So it's smart, it's good about it, it just stops the work as soon as it can. Nice.

How can you benefit from these APIs if your non-urgent update happens in a library, like React Query, for example? Sorry? How can you use these APIs if the... Urgent update happens? In, like, a library, in a React Query, for example. That is a good question. So I don't know. The next API you need to wrap like whatever function you have that changes the state, you need to wrap it with startTransition. It does not have to be exactly this at state callback, it could be 10 layers of intermediate functions. But if React Query... I have not used React Query. So if React Query gives you some callback that changes the state, that you could wrap with that, then that's good. If it says the state internally, then no.

Also check out the useDeferredWidgetHook, because it's a different API, and if you can't transition, maybe useDefersedValue will help you. Yeah. Do you know of any libraries that are actually implementing this internally? Like, are there, for example, flags for React Query that you could instruct React Query to do the right thing automatically for certain sets of data? I don't really, and I think the reason for this, there's a good reason for this, the library does not know which parts of the UI are urgent or non-urgent. It's up to you, to the application developer. True.

Okay. So what happens if an urgent update comes in while non-urgent updates are still in the queue? Also great, yeah. So then an urgent update is going to be stopped. React will run the urgent update immediately. And then actually, not sure, like, I think the, so, don't quote me on this, but, my understanding is, if the urgent update changes the non-urgent state, then like React will start rendering the non-urgent state from scratch. If it affects some other part of the UI, then React will just continue what it, like where it posts. I think, don't quote me on this, but I think that's how it works. Nice. Thank you. I will go and tweet it immediately. You said this. OK.

I think all of the other questions here are pretty much answered already. So I think that's all. Thank you so much. Thank you for having me.