React's Secret Weapon: Leveraging Concurrent Features for Top-Notch Performance

I'm happy to be here. Thank you for being here. Thanks Natalia for the introduction. I'm going to be speaking about concurrency within React and how you can use it to improve performance within your applications. And yeah, I'm a software engineer currently working at Spotify.

Before I get into the talk itself, just a bit of background on my journey and how I got into frontend. So it started around 2017. I did study a computer science course or like a heavily tech related course, but I did build a website as part of my degree and absolutely hated it. But I found myself learning HTML and CSS after graduation. And then I did that for a bit and finally got my first role in tech in 2018. And this was basically my introduction into frontend frameworks and more specifically React. And then I worked there for a bit and moved on to a crypto trading startup where I was working more heavily with just React. And then 2022 started a full stack role, which is my first full stack role at Spotify. So I actually work more with backend these days now, but I work Java on the backend and React on the frontend.

Okay, enough about me. So today, here's a quick agenda, what I'm going to be talking about. Starting with a bit of background on the performance problem. So why are we talking about concurrency in the first place? And then we'll talk a little bit about concurrency under the hood. So how React actually is, how React achieved concurrency. We'll look at the main concurrent APIs that were introduced in React 18. I'll talk through some use cases briefly and then some drawbacks because everything comes with a drawback. All right. So if you think about the applications you use on a day to day basis today, Instagram, Twitter, those applications rely on giving immediate feedback to the user, right? When I scroll through my Instagram feed, I'm getting feedback immediately. And the applications that we build today have become increasingly complex, right? Compared to many years ago. So there's more data that these applications have to handle, which means more renders, more computation. And all of this essentially means there's a higher chance of an increased burden on the performance of these applications. So essentially, this is kind of where concurrency comes in. It's crucial to optimize for responsiveness to ensure that the user experience on these applications are as good as possible.

So here. And on to the main subject.

The what and the how of concurrency. In a nutshell, concurrency is the ability to manage multiple tasks simultaneously, such as rendering the user interface, responding to user input, processing network requests, and doing all of this without blocking or slowing down the main thread. So let's look a bit into the background of this and how React actually achieves this.

So top image, synchronous, bottom image, concurrent. And the rendering process in React is broken up into two phases. So there's the render phase, and there's the commit phase. So if you look at the first image, you notice that the render phase, which is where React will compare the existing DOM to the virtual DOM, calculate the diff, and basically do this computation and determine what changes need to be made. And then the commit phase is where React will actually apply these changes to the DOM.

So if you look at the first image, it's just one long continuous block of rendering, right? And then we have the commit, and then we have these tasks. And what that means, typically, pre-React 18, is that the render phase could not be interrupted. So when I load a component or a page, React has to complete that render phase before the user can actually interact with the web page. So the commit phase, as you can see, basically makes this process interruptible. So if you look at the bottom image, you notice that this render phase is broken up into small chunks and essentially, React has created something quite intelligent, where instead of rendering everything all in one block, it can actually interrupt this render phase and the user can prioritize user interactions between the render phase.

So notice that we have these small chunks of rendering. We have a task, which could represent a user event like a click or typing. Then React goes back to the render, handles the task, and it's that back and forth, which means that our applications have a more fluid user experience, and then they're more responsive.

So here's a very basic, very high-level, amateur-ish diagram that I created to kind of represent what goes on behind the scenes. We see our web browser, we see the React application, and then we see something called a task scheduler. This scheduler is sort of like the engine behind this concurrency model.

So what it does is, firstly, I've mentioned that the work or the render is broken up into small units, right? This concept is called time-slicing, so the render work that is required is broken up into chunks. And then what the scheduler does, it looks at all the tasks that need to be handled and prioritizes them and then executes these tasks. So a high-priority task can be considered as a user clicking into an input field, or a user trying to scroll or typing.

So a high-priority task can be considered as a user clicking into an input field, or a user trying to scroll or typing. Yeah, clicking a button, for example, that's high-priority because, like I said, the user expects immediate feedback, right? I don't want to click on a button and it freezes. And the lower priority is fetching data from a backend or rendering some kind of long list.

So this task, this built-in task scheduler, basically assigns this priority to the different tasks, and then it yields control back to the browser every five milliseconds. So whenever it notices there's a click on the screen, it will basically say, browser, this is important, handle this. Once that's done, React takes over and continues rendering. If there's another click, it yields control back to the browser and so on and so forth. And it does this by default every five milliseconds. So basically just checking continuously whether there's any high-priority task that needs to be completed.

These are screenshots I took to kind of make this more real from the scheduler package on React's official repository. So notice on the left, we have this work loop function. Again, like I said, this continues checking for high-priority tasks. And then to the right, there's a function called should yield to host, and that's what determines whether host beamed the browser. In this case, that's what determines whether React should give control to the browser or continue the render process.

Okay, so on to the more practical things now. So we kind of know how all of this is working behind the scenes. And React has abstracted away all this complexity from the users, which is you and I, via these concurrent APIs. So when version 18 was released, which is when concurrency really was introduced, they released these two new hooks, useTransition, useDeferredValue, and then the extended suspense for data fetching.

So I will talk through each of these, starting with useTransition. Essentially, this allows us to assign priority to a state update. So just like I mentioned before, the task scheduler uses a priority queue to determine what's important, what's not important. useTransition is what allows us to actually handle this priority as users, as end users of React. So in the code on the left, it's just a normal hook. So it returns two values, an isPending flag, which is a Boolean value, and then it returns a method called startTransition. And if you look inside this handleClick method, we have this setText, which is considered a high priority task. Maybe that's not the best example, but just to compare it to setTheme, which is wrapped inside this startTransition method, and that's considered lower priority.

So whenever you have any state updates inside startTransition, it's considered a transition update, which is not as important as the other updates or the other things that need to be rendered. You can also directly import this startTransition method. So if for some reason you don't want to use a hook, or you can't use a hook when you're on those specific components, you can use the startTransition method, import it directly from React. Okay, so I hope this works.

Oh, okay, I think it's going to keep looping. But these, the next series of slides are videos from the React 18 working group websites that I pulled. It's basically a website that has this chart, and this, I think it's called a bubble chart, and it has this slider at the top somewhere at the top left, where you see minimum score. I'm not sure if I can get this to replay. Maybe if I go back.

So if you note, this is an example of this transition or this interaction happening on a fast computer that does not use transition or the useTransition hook. And just go back again. So notice as you're sliding, the content is changing based on what value the slider is on. So this one looks normal. But this is what it looks like with a useTransition. So again, notice that the bubble chart updates are much, they don't happen as soon as you slide. Again, kind of helps the user determine, okay, I'm on this score now, and this is like, there's a slight pause. And this is even more prominent or more pronounced with slow computers.

So here's another example, a slow computer that doesn't use transition. And notice how much lag there is. And this happens quite often. You visit a website that's handling, say, a lot of data, and we're trying to move something or click something, and it just lags. So I'm going to go back again. So just to see that lag. And yeah, there was even, I think, some failure there, but it's not a positive user experience. I think we can all agree on that. And then here's the example with useTransition on a slow computer. So for this to work, they actually throttle the CPU speed, just to see the effectiveness of this. So I'll play that again. And you see that the slider is not frozen, so I can move back and forth quite easily. And notice this, like, the bubble charts kind of fade slightly, which kind of indicates some kind of loading state, and they're using the isPending flag to be able to do that. So overall, it kind of makes for a more pleasant user experience. Play that one more time. As we slide, we can slide easily, and then the data is returned to us on-demand. So in this case, the chart updates are considered, or have been wrapped inside a startTransition method, and they're considered less priority.

And the slider is considered a high-priority update, so React will prioritize that movement and then handle this bubble chart update afterwards. Use deferred value. So this is quite similar to useTransition, but instead of assigning priority to a state update, what we can do with this is basically defer the updates of a value on the UI. So if there's a value that I have, and I don't naturally need it to be updated immediately, I would then use this hook.

So it's specifically for values that might potentially affect my user experience that are not critical to the user's, to the components, or not to the components, to the user interaction, rather. So here, I just have defined the hook like normal. It takes in the value that you want to defer, and then it returns that value back to you. So here, deferred is just in a p tag, and it's considered less priority than the rest of the page.

So here's another video. It's just basically, I created this simple, just an input field, and as I type, it essentially displays what I'm typing into that input field. I've also added that red dot there, just so you can indicate when I'm actually typing. So notice again, the amount of lag there is, and just also the list that's displaying this input field has actually been artificially slowed down. Again, to kind of show how this works in practice, and then here, I'm using the hook. And you kind of notice the change. So I've defined the hook there, and the value that's returned by the hook, I'm then passing that into this slow list component. So notice again, as I'm typing, there's no lag. The red dot is there more permanently, and then the data doesn't update immediately. So again, the names don't necessarily need to be displayed immediately, but as I'm typing, which is a high priority task, I want that to happen, and I want immediate feedback.

And then the last concurrent feature today I'm going to be talking about is Suspense for Data Fetching. So Suspense has existed since React 16, but in React 18, they've essentially extended the functionality of Suspense. So typically, we would use Suspense to lazy load a component, so if we don't necessarily want the component to be rendered when it's not needed, we would use Suspense for that. And then now, what we can use Suspense for is to basically pause the render of a component until the data it requires has been resolved. So here I have an example. This data variable has to use async data, and essentially, that Suspense should have a component inside it, but the component would only be rendered after I have the data that the component is using. So here I have two examples, Data Fetching before and after. I have this ArtistList component, and this is how we typically would do it today. So we would have a useEffect where we would call this API, we would have a setIsLoading to true, and then set that to false once the result has resolved. And then I have this loadingArtist to check when loading is true, and then I'm just rendering the data. So on the right, I'm pretty much doing the same thing, but I'm using Suspense which can now handle Data Fetching. So here I have my ArtistList component wrapped inside the Suspense.

I have my fallback, and notice I don't need the useEffect anymore. I've defined the ArtistList function at the bottom, and then again, the data that you see defined there that's equals to resourced or re-data is the data that the ArtistList component needs. And essentially, until this ArtistList component has, or until this data has been resolved, then the component is basically suspended. So React pauses that render until the data is ready. And just one caveat here is that this currently only works if you're using some kind of Data Fetching library like React Query, so the Data Fetching mechanism needs to be Suspense aware. So this typically wouldn't work with just like regular fetch calls without any library.

Okay, so now that's done, with one of the examples, I basically did a quick recording of the performance. So I did some profiling here, and you can see the top one is the synchronous version, the bottom one is the concurrent version. So I think this was, I used the useDeferredValue example with typing the artist's names. If you focus on the top image, you can see this red bar and in Chrome that represents what is considered a long task. And I've put in brackets there, if you hover over it, that took 403 milliseconds. So again, you see this, the chunks are much longer compared to the bottom one when I added this useDeferredValue hook, and you see that the tasks are much, much smaller. So this is how React kind of handles these events or these tasks in small chunks. Oh, and yeah, 0.1 milliseconds per task, whereas the other one was 403 milliseconds per task. So lots of practical work that we've just looked at here.

How do you actually use this, or when do you actually use this for other? These are just a few examples, there are many more than you might imagine, but I think these are the most common examples that I wanted to highlight. Firstly, handling real-time search inputs. So if you have a search field that renders some kind of data every time you type into it, so depending on what inputs you've typed into it, it returns data to you. Concurrency is great for that because again, preventing UI freeze. And then seamless tab or component switching. So React has a good example on its docs, actually, of how this works. If you have a few tabs and you're switching between them quite quickly, and say those tabs depend on data coming from a server, the button or the tab itself, the clicking might freeze. So you would use something like start transition to set this set tab as a low priority update. And then rendering large lists. So again, this is resource intensive. And then finally, show animations and transitions, so anything that might potentially affect the fluidity of animations or transitions on a webpage.

Drawbacks. The important stuff. So yeah, there are a few drawbacks with concurrency, so it definitely does come at some cost. Firstly, it may actually delay the non-urgent updates. So what we're doing is we're setting specific updates to be not as important. So we're saying de-prioritize this and prioritize something else. And this could actually have an adverse effect on your user experience, of course, if you're not using it in the right way. So especially if you think of a slow device, for example, the non-urgent updates could actually be much slower than you need it to be. And then it doesn't necessarily have any benefits for expensive components. So if a component is quite large and it takes 500 milliseconds to render, regardless of whether or not you're using concurrency, this amount of time is how long it would take you to render that component.

Thirdly, may add CPU strain. So think of all the things that are happening in the background, all the overhead that React has included. So the yielding to the browser, the scheduling, prioritization, all that stuff. Add some kind of overhead, and if you're using concurrency on a low-end device, or, say, on a task that's, on the other hand, on a component that's already optimized, or on like a CPU-heavy intensive component, it might actually have insignificant benefits for you. So it's important to kind of weigh out the performance trade-offs when it comes to concurrency.

And then finally, I think requires is the wrong word here, but it's more a... If you would like to use concurrency within your applications, it does help to have some background of what's happening behind the scenes so that you can be able to debug better. If there's some weird behavior going on, then you know, okay, this is why I understand what React is doing in the background. So there's just that learning curve for developers.

Concurrency means that React can now manage and render multiple versions of the UI at once. So it's doing all of this simultaneously. Concurrency is not enabled by default, so you actually have to opt into concurrency via these concurrent features that I highlighted. And then finally, it doesn't actually make your application faster, but it makes it feel faster by the prioritization of important user events.

So, and that's everything. Thank you very much for listening.

All right. So we have a few questions that came in, and I'll go through them. And one of the first ones is about suspense and asking, should we use suspense on parent or child level components, I believe? Okay. That's a good question. I think when it comes to, if you're, they're asking specifically about suspense for data fetching, if you consider any application that, so I think the benefits of suspense is that it kind of allows you to split up this data fetching logic from the application that actually uses it. So you can have your logic in another component that's wrapped in suspense and then have this child component where you're just rendering the UI or the data that's received. So I would say to use it in the parents and then in the child, you just render the data that's returned.

Awesome. Thank you. And by the way, I just want to remind everyone as well, please scan the QR code as well and give your rating. You can rate the talk out of five stars. And we've got a few more questions coming in. And this one is about what's the benefits of using transitions over some form of like a de-balance as well? Yeah, that's a good question. Definitely something that users kind of consider. So I think use deferred, use transition or use deferred value. Those hooks are very focused on the user interface responsiveness, right? Whereas something like de-balance has, I think I would say a broader scope where you can kind of control function calls. So if you have a use case where the responsiveness or the interactivity has some kind of performance issue, then I would say use deferred value or use transition. But if it's, I guess, broader than that, and you're trying to say, limit the amount of times a certain function is called within your component, then de-balance works better for that. So those hooks are very focused on UI responsiveness and ensuring there's like a smooth interaction between the user and the application.

I love that. And also the kind of distinction between there is something maybe being performance in a background and something feeling performance to the user and using the right tool to get one of those. The next question, because we always think about testing and making sure that we can test our code, how does this affect testability? Or are there some ways we can test or implement tests on these kinds of things? Good question. I think so. I kind of focused on this performance profiling when it came to kind of testing the actual effectiveness of these hooks. So that's one thing you could do, kind of measure or profile what was happening before and what's happening now. But I think I wouldn't say there's any significant differences when it comes to testing. I think it's more just being able to identify whether or not these before you diving into using these hooks, being able to identify whether the, I guess, the results or the what you would like to achieve is significant enough. Because sometimes if there's like overuse of these features, it could actually have a negative impact on the application. Awesome. Thank you so much.

As you can see, there are more questions, but we do not have time for questions, unfortunately, but she can find her in the speakers Q&A. And also, where can people find you online? LinkedIn, Dara Olaibi, Twitter, Dara Olaibi, Instagram, Dara Olaibi. Awesome. Thank you. Can we get a five out of five round of applause for Dara one more time? Thank you.