Understanding the New Event Loop in React Native

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

If you’re a seasoned React Native developer, you may have been burned by the fact that certain React behaviours just don’t work as you’d expect. We’ve all tried to use useLayoutEffect on our RN projects, only to find that it doesn’t quite behave how the React docs describe it.


All of that will change with the new event loop coming to React Native as part of the effort to bring React Native closer to Web APIs. 


Strap in for a wild ride where we dig into the depths of how the event loop currently works, how it will change, and what this means practically for us as React and React Native developers.

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

FAQ

The new event loop in React Native is part of the new architecture that allows for synchronous communication between JavaScript and native layers, improving performance and aligning React Native more closely with React DOM.

The new event loop is important because it enables synchronous updates and access to layout information, making React Native behave more like React DOM and improving performance by reducing UI flickers and inconsistencies.

The new architecture replaces the asynchronous bridge with a synchronous JavaScript Interface (JSI), enabling direct communication between JavaScript and native code, reducing latency and improving performance.

The new architecture introduces synchronous communication, type safety, improved performance with the Fabric renderer, and better support for modern React features like Suspense and transitions.

The new event loop processes tasks and micro-tasks sequentially, ensuring that all micro-tasks related to a task are completed before moving to the next task, which aligns with the behavior of the JavaScript event loop.

The old architecture faced challenges with asynchronous communication between JavaScript and native layers, leading to stale data and UI inconsistencies due to the asynchronous nature of the bridge.

The new architecture allows useLayoutEffect to work correctly by providing synchronous access to layout information, which was not possible with the old architecture.

Developers upgrading to the new architecture can expect improved performance and alignment with React DOM, though they may face issues if relying on unmaintained libraries that haven't adopted the new architecture.

The new architecture improves performance testing accuracy by properly handling useLayoutEffect and providing more reliable layout and rendering data.

Mo Khazali
Mo Khazali
29 min
25 Oct, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
I'm going over the new event loop in React Native, which is one of the more interesting parts of the new architecture. The new architecture includes the JSI for synchronous communication between layers, new Native modules for type safety and code sharing, and the Fabric renderer for prioritized rendering and support for modern React 18 features. The React Native event loop works differently from the previous architecture, executing tasks and updating rendering. The React Native team can now schedule JavaScript code within React components to execute at specific times, allowing for control over the execution schedule. React Native can now prioritize rendering urgent events, resulting in a more synchronized and flicker-free UI. The goal of the new event loop specification is to align React Native more closely with the web, providing capabilities and behaviors similar to the web. Migrating to the new React Native architecture aims to minimize fundamental changes for existing codebases and ensure proper support from library maintainers.

1. Introduction to React Native Event Loop

Short description:

I'm going over the new event loop in React Native, which is one of the more interesting parts of the new architecture. I'll explain the concepts so that even if you're not familiar with the new architecture, you can still take something away. I head the mobile team at Theodo and organize the React Native London meetup. We're also organizing our first React Native London conference this year.

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.

2. Introduction to React Native Architecture

Short description:

Last year, I performed performance tests comparing different mobile frameworks - Swift UI, React Native, and Flutter. Swift UI outperformed React Native and Flutter, but I was corrected by the React Native and React core team. UseLayoutEffect doesn't work correctly in React Native, but it does in the new architecture, which is now the default. The old architecture had a separation between the JS and Native layers, communicating through a bridge. Communication was async, causing potential synchronization issues and stale data. The new architecture improved this by allowing the React code to directly interact with the JavaScript interface (JSI).

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.

3. Overview of React Native's New Architecture

Short description:

The new architecture of React Native includes the JSI for synchronous communication between layers, new Native modules for type safety and code sharing, and the Fabric renderer for prioritized rendering and support for modern React 18 features. The new event loop synchronizes rendering with the host platform and is inspired by the JavaScript event loop.

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.

4. Overview of the New Renderer and Event Loop

Short description:

On the right-hand side, batching is used to render multiple items together and avoid intermediate states. Transitions can be used to lower rendering priority and prevent blocking the Native thread. The new renderer has three stages: render, commit, and mount. The new event loop synchronizes rendering with the host platform and is heavily inspired by the JavaScript 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.

5. Overview of JavaScript's Call Stack and Event Loop

Short description:

JavaScript is a single-threaded language, executing code sequentially. Errors in JavaScript produce a stack trace, showing the call stack of functions. Long-running tasks can be handled asynchronously using JavaScript's asynchronous nature. The event loop plays a crucial role in managing asynchronous operations. It waits for timeouts to complete and pushes callbacks into the call stack. The JavaScript event loop is simple, checking the callback queue and executing callbacks when the call stack is empty.

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.

6. Overview of React Native Event Loop

Short description:

The React Native event loop works differently from the previous architecture. Rendering is now done in a JavaScript thread, followed by committing in a background thread, and mounting in the UI thread. The challenge arises when the JavaScript thread initiates another render without knowing the previous render's information, leading to incorrect layout data. The old architecture fails to provide the necessary layout information for components like tooltips. The new event loop follows a loop, executing tasks and updating rendering.

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.

7. Execution Order in the React Native Event Loop

Short description:

The React Native event loop executes tasks and micro-tasks in a specific order. Micro-tasks are executed before larger tasks, ensuring that all relevant micro-tasks are completed before moving on. This model allows for the handling of effects triggering other effects by pushing them onto the micro-task queue. As a result, synchronous and asynchronous behavior is fixed, and UI updates can run asynchronously and synchronously for each atomic update.

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.

8. Scheduling and Threading in React Native

Short description:

The React Native team can now schedule JavaScript code within React components to execute at specific times, allowing for control over the execution schedule. Layout effects and passive effects now have access to layout information, resulting in a more synchronized rendering process. The new renderer enables a threading model that can prioritize high-priority events and reduce intermediate states in rendering.

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.

9. Enhanced Rendering and Alignment with React

Short description:

React Native can now prioritize rendering urgent events, resulting in a more synchronized and flicker-free UI. The alignment with React and web specifications brings React Native behavior closer to React DOM, enabling the use of common UI code across platforms. The push to standardize web APIs in React Native and the development of React Strict DOM by the React Native core team further contribute to the alignment between React and React Native.

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.

QnA

React Native Event Loop and Microtasks

Short description:

The goal of the new event loop specification is to align React Native more closely with the web. Full support for microtasks in React Native allows for actual implementation and better performance. It provides capabilities and behaviors similar to the web, benefiting both developers and library maintainers.

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.

Practical Implications of Upgrading React Native

Short description:

Migrating to the new React Native architecture shouldn't be more difficult than any other upgrade. The goal is to minimize fundamental changes for existing codebases and ensure proper support from library maintainers. The update aims to make the code more efficient, handle batching, and enhance suspense mechanisms. However, issues may arise with niche libraries that are not actively maintained.

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.

Rerunning Benchmarks with use layout effect

Short description:

After the discovery of use layout effect and upgrading to the new version, benchmarks were rerun to measure the change. Creating a native component to measure the native paint side improved React Native's performance by about 15-20%. Rerunning the benchmarks with use layout effects may provide further insights.

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.

Accidental Rendering Slowdown and React Behavior

Short description:

Accidentally queuing too much work can slow down rendering. Running tests showed no massively detrimental effect, but creating a React component that blocks the thread can significantly delay paints. React prioritizes aligning with browser behavior, and any such use of React features would be considered a bug or inefficient code.

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.

Conclusion and Coffee Break

Short description:

I work at another consultancy. The Odo, yes. Running out of time and questions. Disappointed in the crowd. Coffee break for 20 minutes.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Raising the Bar: Our Journey Making React Native a Preferred Choice
React Advanced 2023React Advanced 2023
29 min
Raising the Bar: Our Journey Making React Native a Preferred Choice
Watch video: Raising the Bar: Our Journey Making React Native a Preferred Choice
This Talk discusses Rack Native at Microsoft and the efforts to improve code integration, developer experience, and leadership goals. The goal is to extend Rack Native to any app, utilize web code, and increase developer velocity. Implementing web APIs for React Native is being explored, as well as collaboration with Meta. The ultimate aim is to make web code into universal code and enable developers to write code once and have it work on all platforms.
Opensource Documentation—Tales from React and React Native
React Finland 2021React Finland 2021
27 min
Opensource Documentation—Tales from React and React Native
Documentation is often your community's first point of contact with your project and their daily companion at work. So why is documentation the last thing that gets done, and how can we do it better? This talk shares how important documentation is for React and React Native and how you can invest in or contribute to making your favourite project's docs to build a thriving community
Bringing React Server Components to React Native
React Day Berlin 2023React Day Berlin 2023
29 min
Bringing React Server Components to React Native
Top Content
Watch video: Bringing React Server Components to React Native
React Server Components (RSC) offer a more accessible approach within the React model, addressing challenges like big initial bundle size and unnecessary data over the network. RSC can benefit React Native development by adding a new server layer and enabling faster requests. They also allow for faster publishing of changes in mobile apps and can be integrated into federated super apps. However, implementing RSC in mobile apps requires careful consideration of offline-first apps, caching, and Apple's review process.
React Native Kotlin Multiplatform Toolkit
React Day Berlin 2022React Day Berlin 2022
26 min
React Native Kotlin Multiplatform Toolkit
Top Content
The Talk discusses the combination of React Native and Kotlin Multiplatform for cross-platform app development. Challenges with native modules in React Native are addressed, and the potential improvements of using Kotlin Multiplatform Mobile are explored. The integration of Kotlin Multiplatform with React Native streamlines native implementation and eliminates boilerplate code. Questions about architecture and compatibility, as well as the possibility of supporting React Native Web, are discussed. The React Native toolkit works with native animations and has potential for open-source development.
“Microfrontends” for Mobile in React Native
React Advanced 2023React Advanced 2023
24 min
“Microfrontends” for Mobile in React Native
Top Content
Watch video: “Microfrontends” for Mobile in React Native
Micro frontends are an architectural style where independent deliverable frontend applications compose a greater application. They allow for independent development and deployment, breaking down teams into feature verticals. React Native's architecture enables updating the JavaScript layer without going through the app store. Code Push can be used to deploy separate JavaScript bundles for each micro frontend. However, there are challenges with managing native code and dependencies in a micro frontend ecosystem for mobile apps.
Building Cross-Platform Component Libraries for Web and Native with React
React Advanced 2021React Advanced 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
This Talk discusses building cross-platform component libraries for React and React Native, based on a successful project with a large government-owned news organization. It covers the requirements for React Native knowledge, building cross-platform components, platform-specific components, styling, and the tools used. The Talk also highlights the challenges of implementing responsive design in React Native.

Workshops on related topic

Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
Detox 101: How to write stable end-to-end tests for your React Native application
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
How to Build an Interactive “Wheel of Fortune” Animation with React Native
React Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
Top Content
Workshop
Oli Bates
Oli Bates
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
Deploying React Native Apps in the Cloud
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Cecelia Martinez
Cecelia Martinez
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
Effective Detox Testing
React Advanced 2023React Advanced 2023
159 min
Effective Detox Testing
Workshop
Josh Justice
Josh Justice
So you’ve gotten Detox set up to test your React Native application. Good work! But you aren’t done yet: there are still a lot of questions you need to answer. How many tests do you write? When and where do you run them? How do you ensure there is test data available? What do you do about parts of your app that use mobile APIs that are difficult to automate? You could sink a lot of effort into these things—is the payoff worth it?
In this three-hour workshop we’ll address these questions by discussing how to integrate Detox into your development workflow. You’ll walk away with the skills and information you need to make Detox testing a natural and productive part of day-to-day development.
Table of contents:
- Deciding what to test with Detox vs React Native Testing Library vs manual testing- Setting up a fake API layer for testing- Getting Detox running on CI on GitHub Actions for free- Deciding how much of your app to test with Detox: a sliding scale- Fitting Detox into you local development workflow
Prerequisites
- Familiarity with building applications with React Native- Basic experience with Detox- Machine setup: a working React Native CLI development environment including either Xcode or Android Studio
Building for Web & Mobile with Expo
React Day Berlin 2022React Day Berlin 2022
155 min
Building for Web & Mobile with Expo
Workshop
Josh Justice
Josh Justice
We know that React is for the web and React Native is for Android and iOS. But have you heard of react-native-web—for writing an app for Android, iOS, and the web in one codebase? Just like React Native abstracts away the details of iOS and Android, React Native Web extracts away the details of the browser as well. This opens up the possibility of even more code sharing across platforms.
In this workshop you’ll walk through setting up the skeleton for a React Native Web app that works great and looks awesome. You can use the resulting codebase as a foundation to build whatever app you like on top of it, using the React paradigms and many JavaScript libraries you’re used to. You might be surprised how many types of app don’t really require a separate mobile and web codebase!
What's included1. Setting up drawer and stack navigators with React Navigation, including responsiveness2. Configuring React Navigation with URLs3. Setting up React Native Paper including styling the React Navigation drawer and headers4. Setting up a custom color theme that supports dark mode5. Configuring favicons/app icons and metadata6. What to do when you can’t or don’t want to provide the same functionality on web and mobile
Prerequisites- Familiarity with building applications with either React or React Native. You do not need to know both.- Machine setup: Node LTS, Yarn, be able to successfully create and run a new Expo app following the instructions on https://docs.expo.dev/get-started/create-a-new-app/