Modernizing Your React App: Compiler, useEffectEvent, Activity & Friends

My name is Victor and I'm here today to present to you a story of a developer, me, going for a codebase and inheriting a lot of decisions. And probably like me, you also pass for the same situation. When you get a codebase, you know, it's not necessarily new and you go for a lot of memos, use effects, use callbacks, hacks, everything that looks a bit strange. And you're probably going to ask yourself, like, what can I do here? There is a better way. And the answer is probably yes, but it also requires to take active action. And I'm here today to share the story with you with real user cases, examples. Right.

So my name is Victor Alenkov. I'm a software developer with more than 10 years of experience. I've been a manager, I've been a tech lead. Today I'm a staff engineer at Chili Piper. We work with LLMs, chatbots, and AI. And I'm here today to talk to you how you can take advantage of React's latest updates to make your codebase cleaner, to fully understand why those tools are there so we can make our work a better place.

So this is our agenda for today. I wanted to talk about the React evolution over the years to really understand how those updates are coming and understand deeply how those new APIs with React 19.2, how they work, when we should use it, what we can do with them. Then I'm going to give to you this modernization playbook where you can follow step by step, as I did, to land in your codebase those changes to be prepared to change. Not at once, but with a lot of confidence. And then we're going to discuss some opinions and we have some wake-up call.

Okay, so React 19 brought us a lot of perspective on how React is evolving over time. If you're like me, you probably jumped right into this release to understand what was new, what was different, how React was evolving. And truly see the difference in the paradigm and how they're bringing those differences to us.

First, I think the most important thing to understand is the direction, right? So we basically have two paradigms here. The imperative model where we give step-by-step instructions on what to do, how to describe your state and those changes step-by-step.

And putting this in a real example, we have forms in the React 18 pattern, where you have your state and you have a state for errors and you have your handlers, which first will treat your form. Then we'll define the state of your spinner, for example. And then you're going to do the data fetching and if something fails, you catch. And this is how we basically treat your failure state and you have to do this for every other form and for every other state. And over time, it can become confusing.

And then what are the options for this? So we have what React is pointing to, which is evolving to, which is a more declarative model, where you describe the changes before and after, and you let the computer figure out the steps in between. So if you're like me, you're probably already using, and if you're not, I want you to start to use today, the use action state, for example, for forms, where we can use this hook to describe the state of a form. We have the previous state and the form data, and here we have a more declarative model to express our changes. Here, we do the data fetching and we return, and then if something fails, we propagate the failure. So here we have in a form a much better way to detect those changes without blocking each other, right? And this is, for sure, a bigger paradigm shift, because before, imagine in applications, in real cases, you're going to probably have lots of forms.

Just think about lots of try catchings every time. So if you're like me, my company, nowadays we have this chatbot, so tons of forms to change. So this, for us, was very impactful to understand and to bring to place. So with React 19 and going onwards, we can see that we're moving towards declarative everything, not just, you know, like state, like forms, data fetching, metadata, everything that used to be imperative. Now it's becoming more declarative and this is changing, and that carries over even more to the latest 19.2 update. So we have last October another very good update from React where we introduced new APIs, and I think they are super interesting, and I want us to adopt them. So here in this new update, I separate things that I think that's very important for us to bring to the table and how we can go about them.

So here is more or less what we're going to see today. So we're going to have the activity, the user effect event, and we have some performance updates as well. And where do we begin? Right, so let's start by the React compiler. If you see my latest talk and the previous React Summit, you probably know that I'm all about the React compiler. I think React compiler brings to you the biggest return of investment because with one line of code, you can do so much. But to recap, I would like to go through the steps that I take every time that I'm explaining the compiler because I know the sensitive topic as well. A lot of devs are very much afraid to touch the compiler and understandably, it can seem a lot. But once you understand how things work and actually that you can get even more power than just manual memorization, you can clearly see the step by step how to approach this kind of change. So probably if you're like me, you also learn from before how to take your components, take your actions, and make the memory safe, basically memorizing everything. So for the derived data, you used to have the used memo, which you can, you know, memorize the results of the derived data for the handlers. You know, you can have used callback to memorize our callbacks. And for the component itself and the children, we have the React memo, which was, you know, in charge of the memorization and everything else. That is OK. And you know, we see nowadays that a lot of frameworks evolved and they have this baked by default and what React did, you know, it brought to us that API to deal with this stuff. First of all, the name is a bit confusing. We have used callback, used memo and React dot memo. And it is prone to error. Right.

Like this is very manual. We are basically doing the compiler job by hand. So it just takes one wrong call here. So use all the benefits that you gain from memorization. Right.

So what's the alternative? First of all, we install the compiler and we run the health checks. Make sure to add this plug in to our application and from their point on in the compilation time, we can definitely see the benefits of the compiler, which goes way beyond what we can do with manual memorization.

So after enabling the compiler, this whole component becomes a just clean React component where we have our derived data, the handlers and the component. It's much easier to understand. And it's also cleaner and smaller. It's safe for your tokens if AI is reading this code because it's less code. Right. So it's much easier to understand for us. This is a lot less cognitive load, which is great. With React compiler, we basically can think that you're not going to use memos anymore. Callback, React dot memo. It's just functions. Right.

Like we don't have to care about those things. And then if you like me, probably what you're going to do is try to measure how big is the change in your code base right now. So what I did, I wrote a little script to identify how many calls of memorization hooks we had in the code base. And we have a bunch. Right. And I know that this can be like very frightening if you look firsthand, if you're in a huge code base that, oh, my God. That's a lot. But I'm going to tell you later on a playbook how to approach those changes. Don't be afraid. You don't have to do them like you don't have to delete them. You don't have to change the memorization hooks that you already have. We can take advantage of the compiler from installing perspective and evolve from there.

OK, second thing that I want to talk about today is user fact event. Which is this new API that create a functions that see the latest props and state like a DOM event handler, but it lives in the fact world, which basically, and more importantly, means that we don't have to track the dependencies and the linter knows when to exclude them. But let me see, let me show you what I'm talking about. So in our application in the chat room, we have, for example, here this little user fact which, you know, we pass a theme because the user can define which thing they're using. If it's light or dark and I will show a notification to the user once it's connected to the chat room and you probably can see the like the. Bug here, which is now like or not, we have to pass theme as a dependency in the dependency array, even though it doesn't change at all, we have to pass it and it's quite annoying. And what you're going to see many, many times is people doing this little hack that they put the ES lint disable next line, the call out of day and say, OK, I know better than the linter. And we all know that, you know, that's not super nice and probably very fragile as well. But I didn't know a lot of people that actually knew how to solve this without it. And now with react, we have this new API.

So, like before, you know, I create a little script, I start to track those instances, I found a lot of them. And after using the user effect event, we can detach those things, we can decouple those things to have a better declarative codebase. Right here, you use the hook and then you pass the dependency just once, you know, like we have the connected and thin here. And you see now the user effects run completely free of this dependency. So there is no lint suppression because here using the new API, we are smart enough to understand that I get the latest props, but I don't get affected by this user effect anymore. So I can basically decouple those two things, which makes this code much nicer and less prone to error as well. Right. And after this, another thing that I like to bring to you that I'm very excited about is the activity API.

The Activity API brings new strategies to handle state persistence challenges in applications. In scenarios like multi-step form fillers where users navigate back and forth, traditional solutions like conditional rendering or CSS hacks fall short in preserving state. The Activity API introduces a third option with fine control over state preservation and display. By utilizing this React Native API, developers can switch between visible and hidden modes to manage state persistence effectively.

With the Activity API, developers can ensure that when components are hidden, effects are unmounted, cleanup functions are executed, and updates are deferred. Conversely, when components become visible again, effects are remounted, and the state is retained, providing a seamless user experience. This API offers benefits in scenarios like multi-step forms, tabs navigation, and pre-rendering content, allowing developers to maintain data, avoid unnecessary resource consumption, and control the loading of assets in the background.

You know, you can hide things using this display hack. Depending on the type of things that you're trying to hide from the UI, such as effects, fetching data, subscriptions, and timers, you may be wasting resources with traditional methods lacking fine control. The Activity API introduces a third option, enabling precise management of state display to optimize resource utilization. With this React Native API, developers can effectively control when and how data is shown, avoiding resource wastage and ensuring efficient state management.

The Activity API offers two distinct modes – visible and hidden. When in the hidden mode, components are concealed from the screen, effects are unmounted, cleanup functions are executed, and updates are deferred to maintain performance. However, the state remains intact, ensuring seamless transitions when components become visible again. This capability is particularly beneficial in scenarios like multi-step forms and tab navigation, where preserving state while managing resources is critical for user experience.

One powerful use case of the Activity API is in maintaining state across transitions, such as in tabs navigation with multi-step forms. By utilizing the Activity API, developers can prevent data loss when users navigate between tabs, ensuring that the state is preserved throughout the process. Another significant application is in pre-rendering content, where developers can optimize user interactions by loading data and assets in the background based on user behavior. This proactive approach to rendering content enhances user experience by reducing loading times and meeting user expectations efficiently.

So let's think about three powerful user cases. So first, you can think about our tabs example from the past that I mentioned that you have, you know, three steps form. Then if you go back and forth, you lose all the data. Right. So you can see here, using in this case would be very interesting. Here, as you can see, we have the before, which is quite bad. We have the condition of rendering and we end up losing all the state. If we apply the same strategy that I showed before here, you're going to be able to avoid all of those things and maintain the state. So if the user goes from tab A to B and then to B to A again, it will basically be the same as it was before.

Another very interesting example, and here is one of the most powerful ones, is pre-rendering. Just imagine that, you know, you can have a control over the mode of the activity API to determine if you're going to start to load some data, some CSS, I mean, images in the background. So, for example, in our booking flow, we display a calendar with a lot of slots and times. So here, if the user wants to, you know, confirm, we're going to have to go from step by step of like loading the confirmation page and then when user clicks, we set the step. And you know, this takes time and we know every millisecond counts. So here, depending on the amount of data that we're trying to collect, it can take ages and can be very bad for the user.

Another very important use case that we found in the code base was back navigation. So being able to maintain scroll position, it's very important. In here, in the menu views, for example, we have a very, very long list that every time that you have filters and queries and why not, depending on the way that you're going to build this screen, if you go back, everything will be resetted. If you go back and forth, you're going to have to re-fetch everyone, you're going to have to save your state, or you're going to have to create some persistent layers, which can bring a lot of overhead to your application. With the activity API, we have control of the data. So when a user goes back and forth, all the data is still preserved. We don't have to show a spinner, we don't have to refresh, there's no flickering and the experience feels instant.

Imagine like e-commerce is in Black Friday, how much valuable this can be for those cases where every single millisecond counts.

Another very important use case that we found in the code base was back navigation. So being able to maintain scroll position, it's very important. In here, in the menu views, for example, we have a very, very long list that every time that you have filters and queries and why not, depending on the way that you're going to build this screen, if you go back, everything will be resetted. If you go back and forth, you're going to have to re-fetch everyone, you're going to have to save your state, or you're going to have to create some persistent layers, which can bring a lot of overhead to your application. With the activity API, we have control of the data. So when a user goes back and forth, all the data is still preserved. We don't have to show a spinner, we don't have to refresh, there's no flickering and the experience feels instant. So that's very, very valuable for us.

With our codebase, we notice in real results here that we remove 540 lines of code and we start to maintain two hooks that we had internally to control the state, which for us was pretty important. Then let me show you my step by step flow on how to approach those changes. How I approach those changes every time that we have new updates and how I learn those things and how I bring those things to big code bases. So first I like to measure things. And you know, I even prepared to share, if you want this, please let me know, how we identify opportunities in the code base itself. So here, as you can see in this talk, every little API that I want to adopt, I first run some findings with Grab in a code base to try to identify opportunities. So that is actually my first advice for you. You don't have to do it all at once and you can prioritize by impact ratio. So here is what the code base that I'm working on, EU to me, right? Like we go from step by step by step, those new APIs. So we find a lot of link suppressions, memorization, calls, condition renders. And I use this as a guide to understand how much impact I can make in a code base with the new APIs.

So another important thing for us is measuring success and understanding where the things are working, where the things are not working. So here, you know, being able to turn on the compiler, for example, and check the performance using the tools that we have on DevTools. It's very, very important to go through every component that you now memorize automatically and see how they interact with each other, make sure that they are getting the benefits that you try to enable. Also, code quality is not a very good indicator, as you can see for us, after enabling the compiler, running those checks, making sure that we didn't break anything. Reducing the amount of lines of codes was very important. So we can make our AI tools better, more predictable and consume less tokens. And overall, I think developed experience, you know, time to implement new features right now, we have fewer bugs, and it was much more friendly for newcomers to the team to understand the code base. So here's a real number like our PR time to review dropped by 12%. I've removing all this bullet plates, adopting those new features, you know, like we stopped to asking questions, obviously, like, oh, why is the this used memo here? What is doing? It's even relevant or not, you know, that's a measure of good developing experience improvement.

And here, I think it's the part that for me is very important because you could ask me, hey, Vitor, why do I have to learn those new things? Why can I just, you know, ask AI to do them? So first of all, for me, like it's very important that you don't delegate your brain to AI, because especially for changes there are like beyond, let's say the training models, you're going to learn, you're going to see that they do a lot of mistakes and they're not prepared. They can read the documentation and you can use this a memory, but it's not as effective as they run that training model inside of it. And with a lot of examples. So please, please, if you take one thing from this talk, don't delegate your brain to AI, because I know that a lot of people are frustrated, you know, being bombarded by AI every day, all the time. It's quite making our brains feel very much stress. So, you know, being bombarded cognitively, it's a very real thing. So be careful with that. You know, don't delegate your brain to AI. And I understand, right? Like I have two confessions to me. One, as I myself have deployed code that I didn't fully understood. Right. And I'm pretty sure just by statistics, if you're seeing this. You did as well, because, you know, we know the adoption of AI tools is quite high, but. The pressure to deliver, to be faster, it's also quite high. And, you know, the humans become the bottleneck, but we have to take things into control. We have to take control of those things. And we can only do this by learning and really understanding what we are doing. So. I understand where you are right now, because we start to ask, you know, very important questions. But most importantly, you can't debug what you don't understand. Right.

And there's no way I, in a world that will help you with that. So. You know, I probably like many, many people start to have a more stressful life as a developer after AI. You know, there's a lot of benefits. There's a lot of good stuff. No, but there's a lot of questions that we never had to ask ourselves before. That now they're so relevant, right? Like we are bombarded by new things every day. And I understand that this can feel very stressful, right? Like now we have more people contributing to the code base, you know, sometimes designers, sometimes PNs. And now everyone wants to be a developer. Everyone feels empowered to be, which is a great thing, but we have to be very careful, right? Like we see the more and more very big security issues are arising more and more pretty much every other day. We are bombarded from those, like news that, you know, like now React is not secure anymore. So it's secure, but not so much anymore. So we have to stay tuned for those things to avoid those big mistakes. So we need to be very, very, very responsible. So this is why I think it's still very much important that we learn those things that we understand and then we use those tools in our favor to make our work easier. But having full control.

So to finalize, to give you a concrete way, how to approach those new updates and you know, how to make your code base nicer and adopt those new APIs. Here it is the step by step again. So you can start with the React compiler. It's just one line of code for you to, you know, install the ESLint plugin, make sure that everything is there and you can run the health checks. And you can see already that your components can go beyond manual memorization. You don't have to delete everything. You can just observe and then stop writing those memorization hooks. Then from medium to high impact, you can start to audit your code base, you know, for like those opportunities where you can replace things with the Activity API, using ActionState, you know, make your code base nicer and also move from like imperative to declarative model.

Then with a high effort, high impact, then you can start to analyze how users are using your application, where are the opportunities for partial rendering and structure components between static and dynamic to be able, you know, to tell with this granular approach when to preload something, when to pre-render something and how you control the data fetching flow. And here to show you this in practice, right, it is this little application that I create just to control how I want to make those updates to the code base. So here I'm running all those checks based on the script that I showed you before, where we can identify every instance of use memo, every instance of like suppression calls for the ESLint that we can use this new APIs and every opportunity for me to adopt, for example, the Activity API as well. The way that I'm showing you is actually the way that I'm implementing my code base as well. So I hope you like it. It was very fun to collect all this knowledge and be able to share here with you. And if you have any questions, let me know. I would like to thank you everyone and see you next time.