Understanding the New Event Loop in React Native

So I'm quite excited to be going over the new event loop in React Native. I think it's a part of the new architecture that's not talked about as much, and it's actually one of the more interesting parts of the new architecture that's kind of hidden away in the footnotes, usually. So we're going to jump into it, and hopefully it'll make a bit of sense. And I'm trying to build up different concepts so that if you're not familiar with the new architecture intimately, you can still take something away from this.

As Jani mentioned, my name is Mo. I head the mobile team at Theodo, which is a global consultancy with around 700 people and 200 mobile engineers. I'm also an organizer in the React Native London community. So we've been doing meetups, the React Native London meetup since 2016. I've been an organizer there since 2019, I believe. 2020. So it's been a really cool ride, and this year we're organizing our first React Native London conference, which is very exciting for us.

Now last year at some point, I went on Twitter and I was just bored at some point, so I decided to do some performance tests, comparing different mobile frameworks to build applications with. So I started with Swift UI, also looked at React Native, and also looked at Flutter, and tried to say, what are the differences, see how they perform in terms of rendering. So I did a test with like 1,000, 2,000, 3,000 views, both with and without text, to understand how these would perform in comparison to each other.

And it got quite a lot of exposure and quite a lot of likes. And you could see Swift UI significantly outperforms everything else on iOS, then React Native, and then Flutter. And I was riding the high horse here, being like, look at this, I've just been a performance expert looking through all of the different frameworks, only to be swiftly told off by people in the React Native and React core team, which was quite an experience. So Svetlan Mikhov, who works on the Hermes engine, tweeted back saying, you know, I'm not an expert here, but I don't think your code works. And then it went all the way up to Eli White, who heads React and React Native at Meta, who was like, yeah, you're using UseLayoutEffect, it's not really going to work correctly. And that's when the bombshell dropped for me, which was that UseLayoutEffect doesn't actually work correctly within React Native. And this was quite shocking, because it's just a core part of React, and if you build on the web, you're just using UseLayoutEffect for a bunch of different things, but it just doesn't work on React Native. And this was true pretty much up until the new architecture. And this is where the new architecture comes in, and according to the React and the React Native core team, UseLayoutEffect finally works correctly within the new architecture. And coincidentally, the new architecture went live two days ago, and it is now officially the default within React Native. So it comes at a very good time.

So a little bit of context for people that aren't familiar with the old and new architecture. I'm not going to stick on this for too long. I swear, everyone's probably heard about it, and they're tired of listening to new architecture talks. But this is the old architecture. And it's a very simplified version of the old architecture, just to try to make it a bit more digestible, but you've got really a separation between a JS layer and a Native layer. And you've got a bridge in the middle that communicates via JSON, so you're serializing and deserializing JSON, and they're communicating between them. So your JS code and the code that's running inside of your JS engine is going to communicate by the bridge and speak to the Native layer to layout things or to call Native code, and that communicates with Yogo, which is your layouting engine. The key thing that you want to know about all this is that all of this communication is happening async, which means that the delivery of this is not going to be done synchronously, and so you don't really know these two layers don't know about the state of each other at any point.

So the React side might have fired an event. It won't know that it's been completely finished on the Native side, and there's no guarantees for it. It would need to asynchronously query to see if that's happened. And so there was a real bottleneck with this bridge. And they could be out of sync because of this communication. And so when it came to layouting and use layout effects, specifically, it meant that the data that the React code had might have been stale and incorrect information, so it wasn't actually the up to date information that was on the ground with the Native layer. And so the new architecture kind of tried to change this. So the React code was directly interacting with what we call the JSI, which is the JavaScript interface.

And that JSI would directly be making Native calls through C++ to whatever the Native host platform is, if it's Objective C, if it's Java or any other platforms that you may have, and we have more and more out of sheet platforms now. The key here is that this was a two-way synchronous communication. So now you could synchronously issue commands between the different layers. And so this is really the core of React Native's new architecture, the JSI.

And this new architecture has a lot of different components within it. There's new Native modules, there's new renders, and there's also the new event loop. So just as a reminder, the new Native modules basically uses that JSI to synchronously communicate between the different layers. It gives you type safety between your JavaScript code and your Native code, which is a big deal because a lot of crashes would happen because there wasn't that type safety. A lot of it is written in C++, which means you maximize your code sharing across all of these different platforms, and it's lazy loading these modules.

Then you have the new renderer, and this starts to tie into the event loop. This new renderer called Fabric was written in C++, and it's shared across all of these platforms. And the key thing here is that it allows for you to prioritize rendering on different threats, and it actually opens up the door for a lot of the modern sort of React 18 features that have been available on the web for a long time to actually work within React Native. So it opens up the door to full-suspense support, transitions, automatic batching, and all of that good stuff.

So the new event loop changes the steps that React Native as a whole takes when it's trying to render things on the JavaScript thread, and that work starts to get synchronized when rendering with the host platform. The new event loop is heavily inspired by the HTML specifications, so it's basically really just taking a lot of inspiration from the actual JavaScript event loop. So it's really important to understand how the JavaScript event loop works first, because if we understand how the JavaScript event loop works, we're pretty much 50% there with the React Native event loop.

But on the right-hand side, because there's some batching, you can see that it renders a bunch of stuff together and it batches that under the hood so that you don't have to have these intermediate states. Because on the left-hand side, that slider is looking a bit laggy, and there's definitely a sort of miss-sync between the Native layer and the React JavaScript layer. So you can also use things like transitions to lower the priority of rendering that you don't necessarily need to instantaneously give feedback. And that way you don't block the Native thread.

So you can see on the right-hand side, what's happening is it's kind of waiting for you to move the slider all the way through and then it renders the largest batch of things, whereas on the left-hand side it's kind of going as you scroll. And so these are the three sort of steps within this new renderer that you need to keep in mind, and this is the event loop ties into this. There's a render stage, then there's a commit stage, and there's a mount stage. Now the render stage is really happening both on the JavaScript layer, it's just generating that React tree that you have, which is the JSON object that defines the structure of your React application or your components that you've got. On the commit layer, you're doing things like layouting and doing tree diffing, and then on the mounts, you're doing the Native layer mounting onto the native host platforms.

So that's the new renderer, which leaves us with the new event loop, which is the topic of this talk. And the new event loop changes the steps that React Native as a whole takes when it's trying to render things on the JavaScript thread, and that work starts to get synchronized when rendering with the host platform. So we'll look at that in a second. Now the new event loop is heavily inspired by the HTML specifications, so it's basically really just taking a lot of inspiration from the actual JavaScript event loop. So it's really important to understand how the JavaScript event loop works first, because if we understand how the JavaScript event loop works, we're pretty much 50% there with the React Native event loop.

So JavaScript, as you know, is a single-threaded language, which means it can only execute one thing at a time, and code is going to be executed sequentially, right? So when you're looking at a call stack that you have, things will get pushed onto that stack, and then they'll have to go top down to whatever's its sort of first in, first out mechanism, right? And so if you look at an example, if you've got a bunch of functions that are calling each other, the call stack kind of looks something like this. So you've got the main execution, then you go into the first function, then there's a console.log, so we can just go ahead and execute that immediately. We'll take that off of the stack, then push the second call there. Then we'll go into the second function, there's another console.log. We can execute that immediately, because it's kind of a little leaf level, so we'll get rid of that. Then we add another thing to the call stack, because we want to go into another function, so we'll go into third, console.log that, and then we can start to pop the things off of the stack, because we've reached the end of each of these functions. So one by one, we'll go through, get rid of that, and we're done.

And so when you see an error is thrown somewhere in JavaScript as well, that's where that sort of stack trace comes from. It's telling you where in the call stack of different functions that you've called, where that error is basically originating from if you go down the tree. And as you might have seen with React Native sometimes, if you do this incorrectly, it can be quite detrimental. So you can have some sort of broken code here, which calls A first, then it calls B, and B seems to call A again recursively, so you can just keep this going, and then you'll end up seeing this, right? It's all because JavaScript is single threaded. It's just because it can go through this call stack and it can only do one thing at a time, and if it keeps on going through that process in a loop, sometimes you can just block the call stack.

So then the question arises, well, it's single threaded, how do we do these long running tasks like making network calls or doing a really heavy computation? And that's where the second component of JavaScript comes in, which is that it's asynchronous, right? So despite being single threaded, JavaScript is also asynchronous, which means that if you want to handle operations like making network calls or things that could block a call stack, you can actually do that asynchronously. And that's where the event loop comes into play. So if you've got a setTimeout, which is a basic example of running an asynchronous operation with the event loop in process, if we go through the same process, we've got the main execution of the whole program, then you do a console.log for first, then you call a setTimeout. Now the setTimeout is not going to actually do anything on the call stack. Instead what it does is it goes into the browser runtime, and it says, it pushes basically a time out there, and it gets rid of that setTimeout from the call stack. So now it's running somewhere within the browser, within the JavaScript engine, and it's no longer blocking the call stack.

And so the V8 container or whatever your environment is, is in charge of waiting for that timeout to happen. So it runs some code within that environment to say, wait for two seconds here. In the meantime, I can run console.log second here. So it goes into the next one, gets rid of that. And once that timeout is done, it can push that callback that I've supplied it to the callback queue. And that's where the event loop comes into play. So the event loop checks the call stack and says, is there anything in the call stack that's currently executing? And if it is empty, what it'll do is it'll look through the callback queue and push things over up into the call stack to execute. So I've pushed back my function there, the function got a console.log, it executes that, and then it can clear the call stack. And so that's how it handles asynchronous behavior. So really the JS event loop is very simple. What it does is it checks to see if there's anything in the callback queue. And if the call stack is empty, it basically pushes all of the callbacks into your call stack and starts to execute them.

So when you're saying a set timeout of 2000, it's not guaranteed that it will run in two seconds. It's guaranteed that it will be pushed into the callback queue in two seconds, but it's going to be anything greater than two seconds. There might be some other stuff running in the call stack. And if the call stack isn't empty, then it just waits, right? So that's the JS event loop just very quickly.

But how does the React Native event loop work? Now before we had the event loop, you'd render in sort of these three different threads and in these three different orders. You'd render and do the rendering mechanism. So we talked about the three stages. You'd render in the JavaScript thread. Then in a background thread, you would do the commit. So that's handling the layout trees and defining and diffing the layout trees. And then finally, you would mount within the UI thread and do that on the native layer. So you would mount those host native components.

The challenge here is let's say your JavaScript thread at this point decides to do another render or do some more computations. This paint that's happening the second time or this render that's happening the second time doesn't actually know any information about the paint that was caused by the previous render. So it could have stale data because the mount hasn't completed on the UI thread. So it could be accessing some data that's just not relevant and not correct information. And so layout information is not going to be available at this point or it's going to be from a previous render. And this could kind of happen multiple times and at different points in your application, you'll have the wrong layout information.

So code like this where you are basically using a use layout effect to get the bounding rectangle of the components on the screen will not work properly and you'll see a UI flicker or it'll just be completely incorrect when you're trying to actually get that information, store it in a state, and then return it to another component. So this is an example of a tooltip. If you wanted to position this tooltip correctly to where the red button is, this wouldn't work with the old architecture because the layout information is not going to be available. What the new event loop does is it's very similar. What it does is it's basically following a loop. So it takes the task that you've got within sort of a queue of tasks that React wants you to execute and it'll execute that task. It'll look for any micro-tasks, and I'll explain that in a second, and then it will update the rendering. So those are the four steps. This is directly from the docs there. And so what it kind of looks like is something like this. We're going to start with just tasks and micro-tasks and then we're going to change it into more substantial and understandable terms. So you've got a task.

What it does is it basically takes that task off of the queue, starts it with the event loop, and then it starts to check is there any micro-tasks that are corresponding to that specific task. So you've got micro-tasks 1.1, 1.2, and 1.3. So what it'll do is one by one, it'll go through those. Even though there's a task in the queue that's a larger sort of task and it's not a micro-task, it'll still execute all of the micro-tasks before it moves on to task two. So it'll go get rid of that, get rid of the next one, and then it will mount that component.

The real key here is the third step, which is executing all scheduled micro-tasks. Because if we put this into a concrete example, let's say we're talking about that button and tooltip example, you might have a render button with tooltip component task somewhere. This is internal React representation and the Reconcilers representation, but I'm just giving an example here to kind of make it more digestible. So let's say you're trying to render the button with tooltip component. Now what they could do is they could say, all right, we've got a few micro-tasks for a use effect and a use layout effect. So what it'll do is it'll take that first, process it with the event loop, process the use effect, process the use layout effect afterwards, and then and only then actually mount the button with the tooltip component, rather than going through these each asynchronously. And this model really works well because what if an effect triggers another effect, right? So we have a micro-task that can a micro-tasks trigger another micro-task.

Well this model and this event loop handles that situation. So if you go through the same steps, you take out that render from React, you pass it through the event loop, that's the main task, then you go through the use effect, then you go through the use layout effect, but that use layout effect actually triggers another use effect. How does that happen? Maybe that use layout effect changes a state within your React component that actually needs to trigger another use effect that you've got in there. So what it can do is then it can push that onto the micro-task queue, and because it's relevant to that specific task, it'll just supersede any of the other tasks that were previously there and any of the other micro-tasks that were there. And so you can take that process-to-use layout effect as you were, process the use effect, and only then handle the actual rendering and the mount there. And so this allows you to fix that synchronous and asynchronous, the asynchronous behavior that you had, and have everything run asynchronously, have everything run synchronously for each atomic UI update that you've got.

And so once you have a well-defined event loop, the React Native team are now able to schedule parts of JavaScript code within React components to execute at specific times, and they can mark things as tasks and mark things as micro-tasks, and they can really get control over the schedule of execution for each of these different tasks. And using this each event loop iteration can really just update a single UI atomic update. So straight from the docs, what this means is refs, layout effects, and passive effects are going to now have access to the layout information of the components that are rendered synchronously, and you will wait and block the paint until this is completed. And so this combined with the new renderer actually means that you can have a really interesting threading model as well. So if you have a JS, let's say we've got a JS thread and a UI thread here, if you have an event that needs you to change some stuff on the screen, what you can do is you can handle the render on the JS thread, then you can commit, and then you mount. So this is the default. You do some stuff on the JS thread, and then you mount on the native layer.

But with this new model, you can also move everything to the UI thread if there's a really high priority event that's happening. So if the user touches a native component somewhere and it needs instantaneous feedback, you can just move the execution into the UI thread. But by supporting these multiple threads, React can actually start to interrupt and prioritize to render more urgent ones. So if you're calculating something on the JS thread and there's a high priority event on the UI thread, you can trigger that event on the UI thread and then complete your JS rendering because this is all done synchronously.

You can complete the rendering on the JS thread and really just do a single mount at the end. So you get rid of a lot of these intermediate states that existed before that would cause flickers and wouldn't look good or would just be completely outright wrong. And so, again, the key here is that the layouts can be read synchronously, which wasn't the case before. And it just led to a bunch of weird behavior that wasn't in line with React's programming model.

Now, you might be wondering, why in God's name does this matter? There's a few different things. So the two, if you look at the RFC directly, there's two main important consequences. The first one is that React Native now starts to behave a lot more like React DOM. Before this, the behaviors were very, very different. Layout information wasn't available when you were executing layout effects and the paint wasn't blocked. All of this would happen on React. And so, these differences are being removed and things are becoming more aligned with React. So this alignment with the web specification and alignment with React is actually very heavily in line with where the rest of the React Native ecosystem is going. There was an RFC, I think it was last year, where there was a movement to try to push web APIs into React Native and try to standardize around web APIs, rather than having these native layer APIs that aren't standardized around any sort of specification. And so, that is still underway. There's still a lot of interest in that RFC. And so, there is this general push. If you look at the React Native core team, they're also working on, as we saw in the last talk, React Strict DOM. So a way where you can try to use common UI code across React and React Native, and rather than using React Native web, finding a better and more efficient solution to that. And this is already being used by Meta in production. So there's this push. And again, Meta doesn't live by this mantra of write once, run anywhere. But generally, the ecosystem is moving in that direction, where React and React Native code can be more and more aligned. And you can use... You can basically... Developers who are familiar with React can switch to React Native more easily and vice versa. Because it's really just one paradigm, and it's all universal React.

So this is the ultimate end goal and dream that I think everyone's looking at within the community. But why it's most important, perhaps most importantly, is that I can finally align my tool tips using the useLayout effect. Thank you all very much for your time.

This first question is, you know, you sort of like explained towards the end there that the new event loop specification kind of aligns it more closely with the web. But is the behavior sort of developer point of view identical now? Like if I use QMicroTask or whatever, am I to expect the exact same behaviors on the web? Yes. So it opens up the capabilities of that. Now, you wouldn't necessarily... This is more oriented towards arguably library developers. But yes, you could... The whole goal is that React Native under the hood when it's executing within the JavaScript engine does handle microtasks, and it has a priority queue to execute things. So now the full support of microtasks is going to be quite useful, because it's an actual implementation of microtask. If you tried to queue microtask before, what would happen is it would just use some sort of polyfill and use a timer or something under the hood to kind of make it seem like a microtask, but it wasn't a real microtask. And so now you've got an actual implementation, which is quite good.

Nice. Well, then there's a question for sort of, you know, people migrating to new architectures. What are the practical implications for developers? I do remember back in the dark days of React Native, you know, I used a lot of setTimeout to fix a lot of weird bugs. And now those setTimeouts are probably still living somewhere in codebases, and then some poor person is going to... Were they all setTimeout zeros as well? Yeah, yeah. And no, sometimes I throw in a different number that just provides... Just for fun. Yeah, yeah, just to surprise, you know. Just to make the developer really confused when it breaks. Exactly. So now let's say this developer is upgrading the new version. Is like, what are they to expect? You know, like what is the change of behavior here? So obviously the new architecture initiative has been going on since 2018 is when they first announced it. And it's not been made default until now. So six years after. And I think the reason for it was that they were really trying to make sure that there weren't any fundamental changes for you if you have an existing codebase as an app developer. So they worked really hard with library maintainers to make sure that there was proper support. That it was well tested, thoroughly worked on. And that there wasn't any massive surprises for app developers. And so I think a lot of initiatives gone in to try to make it as frictionless as possible. So if you actually go through and update, you know, your application, the claim and the goal for Meta, at least, is that this update shouldn't be any more difficult than any other React native upgrade that you've done. In practice, it might mean certain libraries that haven't adopted it. If you're using a niche library that isn't being maintained actively by the library maintainer, you will probably have some issues, but there are interoperability layers here. I think from an application code perspective, you probably weren't using things like use layout effect before anyway, because it wouldn't be working. So what this will do is it will either make it more efficient, the code that you've got, because it will handle the things like batching for you, and it will do suspense better, because it's got full suspense mechanisms. So I think it will generally have positive improvements, unless you're using some libraries that are not really being actively maintained anymore.

Nice, fantastic. The most popular question we have here is, in fact, two people asking kind of the same question, which is like, you know, after this new discovery about use layout effect and then upgrading the new version, did you ever rerun your benchmarks from the start of the talk and find out what the change was? I did before the new architecture even came out, but you had to do it in a different way. So you needed to go and create like a native component that would measure it on the native paint side, which was something that the React core team actually gave me a few examples of. And it did improve React Native's performance marginally, about like 15, 20%, if I'm remembering correctly. I hope I could probably try to run it again with use layout effects. Did it improve the performance, or did it just improve your measurements? I'm just the messenger here, okay? Sure thing, yeah. Sorry about that.

Okay, so here's the question. I think this might be related to the sort of the visual graph that you showed about like the different order of operations where you first run the task, then the microtask queue, and then you get to the render. Is it possible for us to sort of accidentally slow down our rendering by sort of using patterns by essentially ending up queuing too much work somehow?

This was actually, so if you look at like the RFC that they did for this and then the work that they actually put in, there was one person, I don't know if it was part of the React team or if it was just a community member who was very much like, this could be really dangerous because you might be blocking like the JF threat for a really long time if there's this sort of queue of events that trigger things over and over again. Generally, it seemed like they ran some tests and it didn't have a massively detrimental effect.

There is one caveat, which is that if you do create a React component as a developer that queues a bunch of microtasks and sort of blocks the thread, then it could delay paints quite significantly. But I think the React team here thought that it was better for it to align with how React behaves because that is how React behaves. If you queue things as microtasks over and over again, you can delay the paints that's happening on the browser. So I think the priority was let's try to make it consistent with how the browser behaves. But as you are aware, like there is no sort of like a legitimate use of sort of React features that would lead into that. Not that I'm aware of. It would be considered and classified at least by the React core team as a bug or inefficient code that you should probably fix, is from my understanding of reading through the discussions that they have there.

Nice. Amazing. Okay. So we have one last question left. And before I ask it, I have to give a little bit of a content warning and maybe ask you, do you find puns triggering? How do you feel about puns? I'm ambivalent to them, but sometimes they- Okay. Well, if anybody finds puns triggering, then it might be a good time to leave. If the call stack is blocked, can you use the software mention instead? Oh, goodness me. Was it the call stack guys sitting here? No, you can't? Okay. Okay. Do we need to explain the joke first? Everyone knows call stack software mention, raise of hands. The two great Polish React consultancies. Yeah, consultancies. Yeah. Cool. Those, that was some good marketing there. I'm impressed with you guys. Yeah. I'm not going to comment on that. I'm not going to comment on the crowd.

No. I work at another consultancy, so I'm not going to comment on that, unfortunately.

Yes. The Odo is it called? The Odo. The Odo, yes. Theodore actually. Theodore. Okay.

Nice. Okay. Well, I think we're just running out of time and we have just run out of questions. I think the last one was maybe one step too far already. I'm deeply disappointed in the crowd. Let's all now grab coffee. So we have 20 minutes for a coffee break. I do have a little, quite tiny announcements if you'll sit for 30 seconds. But we can give Mo an applause and let him go. Okay.