React Advanced

React Advanced Conference 2022

What Happens When You Build Your App

Hi everyone, I'm super excited to be talking to you at React Advanced London. I'm Charlotte, I'm a React Native Tech Lead at BAM, and today we will dive deep inside your application. We will study the inside of your app and what happens when you build it. And then we will see how we can use this information to be more efficient on a daily basis. But let me tell you a short story before. One day I was working at my desk and one big red error appeared on my screen. The kind of error that I didn't understand and I didn't know how to solve. This day I did what I used to do every time back then to fix it. I killed everything. My app, my simulator, maybe even my metro server. And after that second step, I relaunched everything from scratch, brand new. I ran Yarn install, Pod install, I rebuilt my whole app. I didn't understand what was happening inside my simulator. So I wasn't able to identify what piece of the puzzle was failing. So I started everything again. And it worked. But it was wasting a lot of time. And this day, one of my colleagues passed by and saw me killing everything without any pity. And she advised me to try to understand what was happening inside this black box. So that's what I did. And that's what we're going to do today. One quick reminder before we start. For the ones of you who are working on the web, what you need to know about React Native is that instead of using HTML elements like divs and spans, we are going to use React Native core components like buttons and text. And from those components, React Native is going to ask Pnative to create the associated Android and iOS native components. Okay. Let's start. This is a view of a React Native application in our development environment. There are two parts in this schema. A JavaScript part and a native part. On the JavaScript side, we have some code. We have JS, JSX, but also TypeScript code. This code will be transcribed into JavaScript by Babel. The JSX will be transcribed into JS and the JS will be transcribed into an older command JS without any of the new features old machines can't understand. Then we have Mitra. Mitra is a JavaScript bundle, the mobile equivalent of Webpack. It will bundle the JavaScript into a single file that's called the bundle. And React Native will only deal with this single file. If you make some changes in your JavaScript code, Mitra will aggregate those changes to the bundle and refresh your application on the fly. That's about it for the JS. Now let's take a look at the native part. On the native side, we have some native code, either Swift and Objective-C on iOS and Java and Kotlin on Android. If you open your app in your IDE, you will see an Android and an iOS folder. And in this iOS directory, you've got everything you need to create an iOS application. If you're building one in Swift, you would in fact be working within this directory. Now this native code needs to be compiled. And this compilation process is going to produce an executable, an application, IPA on iOS, APK on Android. Those are native applications that we'll be able to install on our phone. Those two applications, the bundle and the IPA, will allow us to build our React Native application. Let's take a closer look at them. This is the inside of a React Native application. It's actually built from the IPA that was executed. A React Native application is really just a native application that will instantiate a JavaScript engine, which will compile and execute the JavaScript bundle. The JavaScript world will be able to communicate with the native world. This goes a little bit like this. Imagine that we have this simple component, rendering a button with a special title. First, the JavaScript will render his button on the screen. To do this, he will be giving instructions to the native to render the equivalent native component. So he goes, please, native, could you render this button for me? And the native goes, of course. Oh, here you go. The user just pressed it. Maybe you should trigger this on press callback of yours. And the JavaScript does it. In our case, it changes the button title. So the JavaScript goes, hey, native, could you change this button title for me? And the native does it. And this is how, as a user, I can now see my new button title on the screen. Now, the communication between the JavaScript and the native is currently being handled through a bridge. The bridge is a queue where the JavaScript and the native exchange JSON messages, like please change this button title. But this will change with the new architecture that you may have heard about. We won't dive into this subject, but the main ideas of this talk will still stand within the new architecture. And if you want to know more about what will change, there will be several talks about this subject at React Advanced. So I'd advise you to listen to one of Nicola Corti's or Gunther Bord's talk. Let's get back to our React Native application. We've got our app. But maybe one day or another, we'd like to have some users and to send it over to some stores. We said earlier that our JavaScript development environment produced the JavaScript bundle. But once we deploy to the stores, we don't have our development environment anymore. We don't need Metro to aggregate any JavaScript change with writes. In release mode, the JavaScript bundle is produced once and for all at build time. And so is the native application. We deployed that to the stores. So great. We've got our React Native application. Before we continue, I had one quick question for you. How do you start your app in the morning? Do you by any chance happen to always run React Native on iOS? I hope not. No, wait. Actually, I do. Otherwise, I'd have nothing to teach you. Anyway, that's what I used to do. But it wasn't the most efficient way to start my day. For the ones of you who are working on the web, React Native on iOS is the command we use to create and run our app. It's a very practical command. It launches a simulator. It builds and installs our app. And we're ready to go. The problem is that this command takes quite some time, about five minutes each time. But what's taking so long? Let's take a look at what happens when we build our app, shall we? We'll be finding here the same elements as in the first schemas, but in a more chronological view. Also, I'm talking a lot about iOS right now, but Android's pretty much the same. And for this part, keep in mind that I'm talking about the legacy architecture, not the new one. But the conclusions will remain the same. Let's get started. This is a view of our React Native run iOS command. When we run React Native run iOS, two things are happening in parallel. On the one hand, we are going to run a metro server. This metro server is going to aggregate all of the JavaScript code into the bundle, transpile it with Babel, and deliver this bundle. But for now, it's a server. It's branched to a port, and it's waiting for instructions to come over. On another hand, we are going to open our simulators and launch it. Then we are going to take care of our native code. As we said earlier, the native code has to be compiled. And this compilation process is going to produce an application, an executable, an IPA that we are going to install on our simulator. Once it is installed, we are going to launch it. And now, two more things are happening in parallel. On the one hand, we are going to load the native modules. The native modules expose native classes to the JavaScript. Those are classes. They need to be instantiated at some point. On another hand, we are going to start the JavaScript engine, which is going to make a request to metro to get the bundle. And at this point, if you look in your network inspector, you are going to see this request made to your own local host. You will also see on the metro server this progress bar. Once the JavaScript engine gets the bundle, it is going to execute it. We will traverse the JavaScript component tree, giving orders to the native to create the native views every time a UI component is encountered. And that's it. Your application is live. Congratulations. Now that we've got this, let's take a look at a few development gestures from the daily life and see how we can execute them efficiently in our mobile world. The first thing you do when you develop is, well, you develop. So you make a change. A JavaScript change. The step we're interested in here is the one of metro. Metro has a listener system that's called Watchman that will listen to the changes you make inside the code. And when you add some JavaScript, it will aggregate it to the bundle and trigger reload. So to see our change in our app, thanks to the hot reload, we really just need to save our code. Now another kind of change, a trickier one that you may do in the code, is a native change. This new native code you added has to be compiled and included in our app. It corresponds to this step in our tree. What we need to realize here is that this compilation process will produce a whole new app and install it on our phone. It will completely override the previous application we had installed. So to see our new native change, we have to rebuild our app. Either by running React Native run iOS or by building it with Xcode. Okay. What else do we do frequently? Oh, libraries. Say that your app is running, you're happily coding, and you need to install a new JavaScript dependency. What you need to do here is just run your install, really. You see, Mitra watches our source code, but it also watches our node modules. So you run your install, and Mitra will aggregate this change to the bundle. But we don't only depend on JavaScript dependencies. We rely on some native dependencies as well. So if you added a new native dependencies by running pod install, which is the command we use to add some native iOS dependency, the iOS equivalent of your install. If you added this new library, this new native library, this is some new native code that has to be compiled as well. So it corresponds to this step in our tree. So you have to run React Native run iOS to build your app again. Now the main gesture that I wanted to check with you today is this one. How you start your app on a daily basis. Just like I said, I used to run React Native run iOS every day to launch my app, but it really wasn't necessary. You see, when you run this command, you go through all of those steps, including the native code compilation, which really takes the biggest amount of time here. But unless you've added a new native library during the night, you don't need to do this. Your app is already installed somewhere on a simulator in your computer. What you need to start your app is really three things. A Mitra server, the device you used the day before, and the application installed on that device. So the process I would recommend to start your app is this one. First you run, you start a Mitra server by running React Native start. Then you launch your simulator. You can do it in command line or using spotlight by selecting your simulator application. And then you have to click on your app on your simulator to launch it. And that's it. It saves so much time already. One small disclaimer, though. Even though I strongly advise you not to run React Native run iOS every day to launch your app, I still advise you to run it from time to time. You see, if you're working on a project where you don't add libraries every so often anymore, the risk is that the one day you need to build your app, it doesn't work anymore. And you don't want to spend three hours debugging this process when you have a new version to deliver to the stores. Let's move on to the last gesture. Testing your app on a different simulator. That's something that I have to do every day. I usually work on a specific simulator, but I have to test my code in different situations with a smaller screen or without a notch, for example. Until I learned about all of this, I used to run React Native run iOS every day to do it. But it isn't necessary. You may start to see why now. You don't need to compile your native code again. Your native code is not specific to a particular iPhone. All you need to do is to take the executable you already built and install it on another simulator. On Android, you can do this by running ADB install. And on iOS, you can do this in Xcode by selecting run without building. You may have noticed that none of those steps include killing me through or your simulator. And that's something that I used to do every time I encountered one of those big red errors that I didn't know how to get rid of. But now that we know what's inside this black box, maybe we can try together to understand those errors and see how we can fix them without killing anything. We basically encountered two main errors related to the balance's problem. The first one happens in the JavaScript, while the other one happens in the native world. Let's take a look at the first one. It tells us that our library could not be found within the project. So it means that we are using a library that we haven't installed. So we just need to install it by running yarn install. And here we go again. This error can also happen in another situation. Imagine that while your app is running, you pull your main branch and someone else added a library. Before you get the chance to run yarn install, you're using a library that you haven't installed yet. So JavaScript is saying, I don't know this thing you're trying to use. So you just run yarn install. But what's instant? Think about this. This library may also have a native part. In this case, you have to install it as well by running part install and to compile it. So you have to rebuild your app by running reg native run iOS. Let's move on to the second error. It tells us that it can't find our library elements in the UI manager. The UI manager handles UI operations like creating native views. When the JavaScript asks for a native element to be created, the UI manager handles that request and transfers it to the native part. And in this error, the UI manager is saying that it doesn't know the native element. So it means our library has not been installed properly. And it's specifically the native part that's missing. We are sure that the JavaScript part was installed. Otherwise, we would have had an error sooner in the JavaScript side. The error we looked at just before, actually. In our case, this error happens afterwards when the JavaScript asks the native to run the components. To fix this, we just need to install the native part by running part install and then reg native run iOS. So I hope that the next time you encounter the red screen of death, you'll understand what's going on behind the hood and you'll know how to handle it. That's it for me. Thank you so much for listening. It was my first talk and I was really glad to give it. Also, please don't kill your simulator. They're nice people.


Charlotte Isambert

React Advanced Conference 2021

Advanced Patterns for API Management in Large-Scale React Applications

Hello, and welcome to Advanced Patterns for API Management in Large Scale React Applications. My name is Tomasz Findly, and I'm a full-stack web and mobile developer with 9 years of programming experience. I'm a co-owner of Findly WebTech and a mentor and consultant at Codementor.io. I'm also the author of Vue and React The Road to Enterprise books, as well as a technical writer for Telerik and The Road to Enterprise blogs. Now, let's have a look at what we are going to cover today. So first of all, we will start with how to manage API requests in React in a scalable and flexible manner with an API layer. Then we will see how to handle different API states while performing API requests. We'll also create custom hooks to manage API requests and states, as well as how to cancel requests with Axios and an API layer. Finally, we'll have a look at how to use React Query and API layer and how to cancel requests with them. Okay, so how can we perform API requests in React? Actually, it's quite simple, right? We can, for instance, use Axios for that. We can just import it and use it in our components. And well, it can work fine for, let's say, small applications. But there are some issues as the project grows, especially large ones, really. So what are the main problems with this approach? First of all, code duplication and lack of reusability. Because imagine that we need to, for instance, fetch information about a user, let's say on the login page, register page, and the user profile page. So all of this would have the same code snippet. So Axios gets a URL endpoint and so on and so on, right? So that's not really reusable. And also, it's hard to maintain because if we had to make any changes to this code, like let's say, for instance, the URL endpoint change, or we had to change the payload format, or let's say we had to migrate from using Axios to something like Firebase, right? We would need to visit every single component that is Axios and change them. Well, that's not really great, to be honest. So let's have a look at how we can fix these issues by implementing an API layer. So first, we would start with the base API file, where we would import Axios and create a new instance with some default configuration, like, for instance, a base URL. Then we'd have an API function that basically returns API wrapper methods around our HTTP client. In this case, Axios. And finally, we export it. Next, what we can do is we can use this base API file and import it in another API file. So for example, in this case, we'd have users API file, because we want to do some things with users like fetch information about users, add a new user, and so on. In this example, we have three methods, list users, get user, and add user. And as you can see, they all use the API methods from the base API file. And how would we use these in a component now? So basically, what we would do is we would import an API method from the API directory, and then just use it in a component. So as you can see, the component doesn't have to think about what kind of API endpoint has to be hit, right? The API method takes care of that. So what about if we wanted to use a different HTTP client? Like let's say, for instance, Firebase instead of Axios. So our base API file would look a bit different. So here we would just import some necessary Firebase methods, would initialize the Firebase app, and then we would export what we need. So for instance, Firebase, Filestore, which gives us methods to basically, well, connecting with the database, and so on, and other things like off storage functions, etc. Now, in the users API file, we would again have the same methods like list users, get user, and add user. However, in this case, we're using Firebase, of course, right under the hood. But let's have a look at how it would look like from the components perspective now. Well, actually, for the component, nothing would change, because it still would import the API method from the users API file, and it would just execute it, right? So that's a really great thing about the API layer, because it's like a black box to your components, right? Because your components don't need to yet don't really have to care about what you use to perform requests, what you really want, you know, it only is concerned with what methods it should call, what kind of input it should provide, and what kind of output it can expect. As long as you can preserve this input and output contract, you don't need to make any changes to your components. You only need to make changes to the API layer, really. Now let's have a look at the benefits of the API layer. First of all, maintainability, as all the API related code is in one place, scalability, because you can easily add new API methods and files. And we also have flexibility, but it's much easier to replace the HTTP client, and also enhance the API layer with custom logic. So as you've just seen, we replaced access with Firebase, and we didn't need to make any changes to the component. And also code reusability, because API methods can be just imported and used anywhere in the application. And well, API layer pattern is also framework agnostic. OK, so next, let's have a look at how we can handle API states. So what I've seen in a lot of applications is basically using Boolean flags, right? For instance, if you want to show a spinner, you would have isLoading state. If you want to show an error, if for instance, a request failed, you would have an isError flag. And let's say if we want to lazily initialize a request, for instance, if a user clicks a button, or if a user scrolls to a certain element, then we can also have this initialized flag, right? So as you can see here, we have three different states, and then all of them are updated accordingly. The problem, however, and here, as you can see, if it wasn't initialized, we display a button. If it's loading, we display a loading data message, can display a spinner. If there was an error, then there was a problem. And finally, if everything went all right, we are displaying the data. But yeah, the problem, however, is that for each API state, we need a new state hook, right? We have initialized, isLoading, isError. So that's already three states. That's only for one API request. If we need to make two requests, we might need to have six states. If we need to make three requests, we might need nine, and so on and so on. But that's not really great. So let's have a look at how we can improve it by using API states instead. And we will also implement a useAPIStateUse hook to help us with that. So first of all, we have four different API states. Idle, which means that basically the request didn't start yet. Then we have pending, which means that the request is being performed. And then we also have success and error. So obviously, success is for when the request is completed successfully, and error if there was a problem. We also have an array here, which basically just exports the constants, as we will need it in a moment. So let's go now to useAPIStateUse hook. So first of all, we need to import useState and useMemo. And we also get the idle constant, as that's our initial state for the hook. And we also get default statuses. And the reason why we need them is because we want to basically take all our statuses and then basically return an object with basically the statuses, like isIdle, isPending, isSuccess, isError, as you can see on the right side on the slide. And only one of them will be active at the time. So for instance, at the start, only isIdle will be set to true. And now here's our useAPIStateUse hook. So we have our state for it. So in comparison to boolean flags, we have only one state that holds all the API statuses. And only one of them can be active at the same time. Then we have the result of prepareStateUses. As I mentioned, basically it's an object that has isIdle, isPending, and so on. And we use useMemo here so that it only re-evaluates if the API status changes. And then finally, we return an object with setAPIStateUses method and all the normalized statuses. Now, let's have a look at how we can use it. So as you can see here, we basically initialize the useAPIStateUse hook. And we can pass the idle there, though it's the default state anyway. If you wanted to start with pending immediately, you can do that. And then we destructure all the statuses as well as the setAPIStateUse method, which then is used to basically update this API status accordingly. Before the request is started, we set it to pending. If it's completed successfully, we set it to success. If there's a problem, we set it to an error. And as you can see in the markup, we can basically just add ternaries, right? If it's idle, then we do something. If it's pending, then we show the spinner or loading message. If it's error, then an error, and so on and so on. So it's much cleaner this way. You don't need to have as many boolean flags. And the code is much cleaner and more concise. So now let's have a look at how we can improve it even further by implementing a custom useAPIHook. So first of all, we import useState again, as well as the useAPIStateUse hook that we've just covered, and three API statuses, pending, success, and error. Then useAPI accepts two parameters. The first one is the method that will execute an API request, and the second one is a config object. So for instance, in this example, we can pass initial data inside of the config object and set it on the state for the data. Besides the data state, we also have a state for the error. And of course, we initialize the useAPIStateUse hook. Now next, inside of useAPIHook, we have the exec function. So as you can see, what it does, it takes care of basically setting API statuses and updating them accordingly, depending on the status of the request. It also takes care of setting the data after the request finished successfully. And it will also handle setting the error if there was a problem. And it will clear it out if a request is supposed to be started again. And finally, the exec method returns an object with data and error if we needed to handle them. Okay, and last but not least, just return everything from the useAPIHook data, APIStateUse error exec, and so on. And now how can we use this hook? So obviously, we need to import it and then just pass the method that is supposed to execute the API request. So in this case, we're passing a method that will just return the result of getUser, which obviously comes from the API layer. And from the useAPI, we receive an object from which we destructure the normal statuses, the data, and the exec method. And as you can see in the JSX, again, depending on the status, we just return appropriate markup. So, you know, for isIdle, the button to initialize fetching, for spending the spinner, and so on and so on. Okay, so how can we cancel requests when using Axios with the API layer? So actually, we can enhance the API layer with abort logic. So in the base API file, we would add the withAbort method that would first accept the function. So this function would be one of Axios methods, like Axios.get, Axios.put, Axios.post, Axios.pat, and so on. Then withAbort returns a function, which, well, basically, these arguments should be the ones that are passed to Axios methods. So for instance, URL, body, and config. Then what we're doing there is we need to get access to the original config. And the reason for it is because as part of this config, we want to pass an abort property, which should have a function as a value. And what we're doing here, if abort is a function indeed, then we create a new cancel method and a cancel token using Axios source methods. And on the config object, we assign this cancel token, and finally, we execute the abort method and pass the canceler there. You will see why we did that in a moment. And finally, after enhancing the config object, we just execute the request. So we forward all the parameters besides the last one. And the reason for it is because we don't want to pass the original config with the abort property. But rather, we want to pass our own enhanced config object that doesn't have the abort property, but might have a cancel token. And note that it's important that we use await here, because if there was an error, basically without await, this error wouldn't be caught in the context of with abort. So that's why we need await here. And then finally, if there's an error, we use Axios's isCancel method to check if the request was canceled, and if it was, we basically set an aborted property on the error object, and we just throw the error feather so it can be handled outside. So let's, okay, one more thing. We also need to wrap, of course, our API wrapper methods with abort. So like I mentioned before, we first pass Axios methods, and then we initialize it again and forward all the parameters. Okay, so here's how we can use it. Now, so imagine basically a feature like, you know, a search box. For instance, a user can enter some query, and there will be an API request made to fetch some information, for instance, for autocomplete. So we have two states, one for the data that will be fetched from the API, and one for the query that the user enters. And we also have the search abort ref. So that's an important part here. The thing is that we need to be able to store the canceler method in between re-renders, right? So that's why we will put it on a ref. But first, let's just have a look at the onQueryChange function. So what's happening here? Well, obviously, we are setting the input value on the query, but that's not the important part here, really. But here, before the request is initialized, we are trying to cancel the previous one. However, there might be no canceler method when the onQueryChange is initialized for the first time. So that's why we use optional chaining operator. So basically, if there's a canceler method, execute it. But if it's not, then that's fine. We don't care, but we don't want the JavaScript engine to throw an error here, right? That's why we use the optional chaining operator. And then next, as a part here, the abort property. So basically, as part of the config object, we pass this abort property that receives a function, and the canceler method is passed as the first argument. And then we can basically assign this canceler on the ref, so that when this onQueryChange is initialized again, we will have access to this canceler. And finally, in the catch statement, we basically check if the error was aborted, right? And yeah, it was. And what's really great about the way it is implemented is that basically the implementation details of the HTTP client, which is accessed in this case, didn't leak into our component at all. We didn't have to import it anywhere. Rather, we only have to provide the abort property, and that's where we get the canceler method, set it on a ref, and voila, it's available for us, and we can just call it. Okay, so now let's have a look at how we can use the API layer with GreerQuery. But actually, it's quite simple, because really what we only need to do is import the API method from the API layer, also import whichever hook we need from React Query, like for instance, useQuery in this case. And then we just use it, right? We pass the key for the query, then we pass our list, well, in this case, list users, so the API method, and we just destructure what we need. So for instance, in this case, we get data, we get the refetch method, which can be used to initialize the request, and we also get our normalized state uses. Again, and this part is basically the same as it was with, let's say, with our own useAPI hook, right? And depending on the state use, we render appropriate content. And how can we cancel requests when using API layer with GreerQuery? Well, again, right? We can basically pass an abort property. However, this time, what we are doing is we're not using a ref, but rather, we have a cancel variable, and we assign this cancel method that was passed through the abort property to this cancel variable. Because the thing is that the way React Query works is that it expects a cancel property to be available on the promise that is returned. So that's why we need to do it this way. It also is very concise and clean. And here, finally, if you want to cancel the request, we just need to call cancel queries. That's it for today. Here are the links to the GitHub repo with full code examples, slides for this talk, and websites where you can find me. What's more, I have a special gift for all the conference attendees. React the Road to Enterprise is coming this December. It's an advanced book with best practices, patterns, and techniques that covers many various concepts such as scalable project architecture, local and global state management, testing, API handling, performance optimization, SSG and SSI with Next.js, and more. You can get 35% off with the code REACTADVANCED. Well, I hope you enjoyed this talk and happy coding.


Thomas Findlay

We Don’t Know How React State Hooks Work

Hi, this is Adam Klein, and this is We Don't Know How Ustate Works. So this talk was born after I heard many times people asked this question on different forums. What about the callback to set states? So people were migrating from using classes and calling set states to using hooks and calling useState. And they were missing this feature that you can add a callback after the state is updated. People asked, how do I do that with hooks? Which made me realize that people just don't know how useState works under the hood. I didn't know how useState works under the hood until I started noticing some strange things when doing console logs. And I decided to open up the React hooks source code. And I found out some great things under the hood, which made me realize if people knew this, they wouldn't ask about the callback of setState. So before we dive into, let's ask ourselves, why do we need to know how it works under the hood? I mean, we're using it, we know how to use it. So there are three reasons, in my opinion. First of all, it's fun to know and get extra knowledge about the framework that we're using every day. It demystifies the magic. The second thing is that we might see patterns that we can learn from and implement in our own projects, which are unrelated to React, even. And the third, I think, is that when you're debugging code and weird stuff happens, it's very helpful to know how it works under the hood and gain more confidence about the code that you write. So let's take this code, which is a simple component. And it uses a state, which is called the counter. And we have a button with an onClick event handler. And in the onClick event handler, we call setCounter. And we pass in an updater function. Now, this could also be a value. But as you know, useState also supports updater functions, which receive the previous value and return a new value. So let's dive into what happens when you call setCounter. And this is what I used to think. Now, I know, and you might know, that React manages the current value of the hooks for us in some kind of ordered data structure, which is a linked list of hooks. And they are called by the order. So what I thought happens is we call setCounter. React sees that we passed in an updater function. So it takes the current value, which is 0, passes it to the updater function, gets the new value, which in our case is 1, updates the current value of the hook to 1, and then triggers a re-render of our component. And our component calls useState again and gets the new value, which React stores, which is 1. So it's pretty simple. The only thing is it's wrong. This is not how it happens. So before I show you how it happens, let's look at some console logs. So here we have a component, which does pretty much the same thing. And let's see what happens when we click the plus button. We have an onClickEvent handler. And we call setCounter. Let's minimize this with the update function. And here we have a console log of update. And here we have a console log of render. And when we click the increment button, let me just move this over here, we render first. And then we call the update function, which is exactly the opposite of what we expect. We expect it to update the value of the hook and then re-render. But it's the other way around. So let's see how this happens. So when we call setCounter, there's actually another linked list attached to each of our hooks. And this is the update queue. So every update that we perform on our state is not performed immediately. It's added to the queue. And it will be processed during render. Let's see how this works. So we call setCounter. We pass in the update function. All React does is put this update function in a queue. And then it schedules a re-render, which means it turns on some kind of flag that says, this component needs to be re-rendered after we finish all of the updates. Now we might have more updates. We might update this hook again. We might update other hooks. We might call the parent component callback, which will update some stuff. We might dispatch some Redux action that will update other components. And all of these updates will be queued. And then at some point, and we will discuss when it happens, React decides to re-render the entire component tree. Or not the entire component tree, the components that were scheduled for re-render from top to bottom. So according to the hierarchy of the component tree. And as I mentioned, we will discuss when this happens later. And now, and only now, when we actually re-render the component, React looks at, we call useState. When we actually call useState during the render, React checks to see if there are any updates that are queued. And only then it will perform these updates. So during render, while we call useState of this specific hook, React will look and see, OK, there is an action. Let's perform it. This action updates the hook to 1. And if there are other actions, it will perform them sequentially until we exhaust the queue. And so let's add another console log. Minimize this. So now, as you can see, we added another console log after useState. So we console log before useState, after useState, and during the update of function. And let's clear. Let's do some updates, clear the log. And when we click plus, you can see that the first thing that happens is that we render. And the second thing is that we call update. So which means that during the call to useState, React runs the update of function. And only then we call after useState, which is queue. It's always good to see for yourself what people teach you. So to summarize this part of the talk, every update to a hook is queued. After all updates are done, the components re-render. And the updates are performed lazily during hook invocation. Lazily means that React performs them only at the exact time when they are needed, and not before. So now we can, first of all, answer this question. How do we call the callback to setState when we're using useState? So now we can answer, when is the state updated? Only during render. So how can we do something after the state is updated? We call useEffect or useLayoutEffect, which is something to be performed after the render happens. Okay. And obviously, we can pass this state as a dependency of useEffect. So we can know when this state was updated exactly, and we can react to it. So this is a standard way to mimic the behavior of the updated function of setState. It's the correct way to do it. What about render bailout? So here, let's say we have, again, a counter, but we set it to the exact same value. Now we expect React to know that it's the same value and not trigger a re-render of our component. But we already said that React only runs the updates during the component re-render. So how can it even bail out or re-render the component if it calculates everything lazily? It doesn't even know that we set it to the same value. So I cheated. There's actually another step that happens sometimes, which is that React eagerly calculates the new state before triggering a re-render. And if it determines that the new state is different than the old state, it will bail out of render, and it will not trigger a re-render. Obviously, it won't do it if we already scheduled a re-render for this component. There's no need to do this eager calculation, because we need to re-render anyway. And also sometimes React will determine that it's not worth doing the calculation. For example, if we already call the same callback a few times, and every time it returns a new value, React just assumes that it will return a new value. So it's just heuristics that React runs to optimize our render time. So obviously, if the new calculated value is different, React will schedule a re-render and will continue the flow, except that because it already computed the new value, it will cache the result inside the update queue. So when we will actually perform a call useState and perform the update queue, React already has this result inside the queue. So it still didn't update the actual value of the hook, but it did store the result of this specific action. So we call the action. We don't have to compute it again, because the result is queued. We update the value of the hook, and we continue with the render. So now, the reason I say I cheated is because every time I showed you console logs, I clicked the plus button a few times to avoid showing you this weird behavior that happens the first time you update the value. So the first time I click, you can see that the first thing that happens is that React tries to update the state. It calls the update function. So for the first time, React says, let's see what happens. And it does the eager calculation, and it sees that the new value is equal to the previous value. And it re-renders the component, and only then it shows after useState. Now the reason that it re-renders is because we actually returned a new value. So we had zero, and the new value is one. So it says, OK, we need to re-render the component. And then when we call useState, one is already cached. So React doesn't call the update function again. And then we get to the after useState. So this is for the first time. The second time, React already dismisses this optimization because the last time we called the update function, it returned a new value. So it just assumes that the next time it will also return a new value. So I don't know exactly how React optimizes this. I didn't see any other patterns. Obviously, it's something that they can change all the time. So it's not part of the documentation. And you can't really rely on how this optimization will work. So what if we calculate the state lazily? But still, it doesn't change. So React didn't do the eager calculation. It did lazily. But still, it didn't change. So does it still re-render everything, even though the only thing that happened was we updated a state to the same value? Long question, short answer, no. It will not continue to re-render. It will just do a shallow render of this component. And if it will find out that nothing actually changed, it will stop there. And you can also check out the React documentation that explains exactly this. So to summarize this part, React sometimes computes eagerly to bail out of render. It caches the eager computation to avoid re-computing. And anyway, if the computation is done lazily and the state didn't update, it will bail out of render and just complete the shallow render of our component. Part three, when does React re-render? So I promised you that I will explain when this happens. So we scheduled the re-render, but when does React actually decide, OK, we're done with updating, let's re-render? So again, let's take an example. We have an onClick event handler. And every event handler in React runs inside a batch, which means that when we call this function onClick, React runs it inside some kind of batch function internally. And every update to a hook will be queued. So the first time we call setCounter, it will add an action to the queue. The second time we call setCounter, it will add an action to the queue. And after the function finishes, it will trigger a re-render. So you probably ask yourself, OK, but what about async functions? If we call something async, then the actual function call is complete before we get to the asynchronous code. So React can't really know that you are trying to run updates to the state. It doesn't know when this async function will complete. So the batch is done immediately. And then every call to setCounter will trigger a re-render to the component. So in this case, with an async function, we will actually re-render the component twice. So this is important to know in case you want to avoid some kind of flickering of the UI or you want to micro-optimize your renders. And then you should know that this will trigger a render twice. It's usually not a problem, but it helps to be aware of the difference between synchronous functions and asynchronous functions. And if you really want to do this inside a batch, you can call React DOM unstableBatchUpdates. And this will do the same behavior as React does when you actually call a synchronous event handler. And so when you call unstableBatchUpdates, it will only render once, even though you updated the counter twice. The only thing is that this is a function called unstable underscore something. It obviously deters us from using it. But it's pretty safe to use it if you really need to, because React, the team realizes that a lot of people use it and some libraries and frameworks use it. So they actually declared it not as part of the public API, but they don't make breaking changes to this API because they realize a lot of people use it. And also they are going to support in the new versions of React, batching updates in a more stable way. So, bonus step is where is the bug? This is more relevant to previous versions of React, but a lot of you are probably still using these versions. So what is the bug with this code? We have an event handler and we call setStep, passing an updated function and we use e.target.value. And the problem with this code, again, in previous React versions, is that we are using e, which is an event, and React recycles the events. Which means that, and now we know that this updated function will only run during the next re-render, where React already could have reused the synthetic event that it is using inside the event handler. So the way to solve this is, first of all, upgrade to new React versions when you don't have this problem. And the second result, if you can't migrate, is just to extract the value before and then use it inside our updated function, or call persistEvent, which persists the event and prevents it from being re-rendered. So to summarize this part, React performs event handlers in a batch, async code won't run in a batch unless we use unstable batched updates or the new APIs from React, and events are recycled, don't use them inside updated functions in older versions of React. Part four, what about reducers? So the answer is pretty simple. Reducer is actually, state is actually a reducer under the hood. And the setState function is actually a dispatch function. We're dispatching the value or the updated function, and the reducer of setState just takes the value and uses it, or the updated function, and uses it on the previous value. So this is actual code from React. This is the reducer that useState uses. It's called basicStateReducer. It takes the previous state and the action, and then it checks if the action is a function, which means we passed in an updated function. It just returns, it calls this action with the previous state and returns the result. Otherwise, we just passed in the new value, so it just returns the new value. So as you can see, we check if it's a function, if it's a function, we call it, otherwise we just return the value, which means that everything that we said about how useState works, it holds exactly the same for useReducer. And now another question, if we dispatch an action, will the reducer always run? Can we guarantee that the reducer will run if we dispatch an action? And so the answer is no, because we only call the reducer during the render cycle. And we might not even get to the render cycle. First of all, there might be some exception that will stop the render in the middle. And second, our elements might be even unmounted in the next render cycle, because remember, we call setState, but we can also call some kind of callback in our parent component. And maybe this callback will change some kind of flag that will hide our components in the next render cycle. So we might not even call the render function of this component again, which means that we just dismiss the queue of the updates, and the reducer won't even run. So again, if you dispatch an action and you console.log inside the reducer, and you don't see the console.log, now you know why. So to summarize, state is reducer. Everything we said about state holds for reducers. And the next part is a bit philosophical. People keep saying that state updates are asynchronous in React. If you search, Google it, you get a lot of different answers, which determine that setState is asynchronous, which is pretty true. But there are a few nuances to know. So like everything in Facebook, it's complicated. So state updates may be asynchronous. Let's just look at some console.logs and describe it the best way we can. So now what I want to show you is onClick event handler I call promise resolve and console.log. So this will be logged immediately after the current event loop, which means after all of the synchronous tasks. Then we call setCounter and we call afterUpdates. Let's clear the log and see what happens when we call the plus. So as you can see, we called setCounter twice, we console.log it twice, and these are the first things that we log inside our console, which makes sense because they happened synchronously. You can also see that the render happened here, and it happened before the async code, which was here, which means that doing the same event loop synchronously, React called our event handler, triggered the rerender, and called our render function of the component. Everything was performed synchronously inside the same event loop. And only after the render was completed, then we saw this async log of promise, which confuses us a bit because we just said that state updates are asynchronous, but we just saw that it happens synchronously. So there are a few answers to this question. First of all, in concurrent mode, it actually could be asynchronous in a different event loop because React may delay the rendering of our components in favor of more prioritized tasks. So it could actually be performed truly asynchronously. And when we do batching, you can look at it as deferred. It's not truly asynchronous in terms of the event loop, but it's deferred. We call the set counter, and then we move on to our next statement. And the render still didn't happen. So it feels asynchronous. So again, this is a very complicated explanation. It's much easier to just think of it as asynchronous, and this is what basically React recommends us. First of all, because of concurrent mode, where it can truly be asynchronous. And second of all, because its implementation details. It doesn't want us to rely on the fact that it happens during the same event loop. So the best way to simplify it is to think of state updates as asynchronous. To summarize this part, state updates are queued and computed lazily during render. React bails out of render if the state doesn't change. Updates are batched inside event handlers, and state is actually a reducer. And lastly, state updates should be considered asynchronous. Thank you. I hope you enjoyed the talk. I surely did, and I hope you learned some cool stuff. And if there are any questions, let me know. And see you all next time. Goodbye.


Adam Klein

React Summit Remote Edition

React Summit Remote Edition 2021

Inside Fiber: An Overview of React's Reconciliation Algorithm

Hi, everyone. My name is Zlat Zemek, and I'm a software developer at Viva Systems in Toronto, Canada. Viva provides cloud-based products for the global life sciences industry, and I currently work there as the lead UI developer for the Safety AI product. Today, we'll be talking about Fiber, React's newest reconciliation algorithm that was introduced in React 16. We'll talk about what React had before Fiber, why Fiber was necessary, and some of the things we can achieve with Fiber. We have a lot to cover, so let's get started. I'll start with a quick demo here, and as you can see, I have a pretty simple app that has an input field, and whatever I type into the input field is then being rendered. We have 80 elements in a list that's being rendered with the value that we typed into the field. So if I type in a lot, we're going to get 80 elements with a text a lot. So my slow list is a component that's being rendered, and if I go into it, we can see that essentially returns us an array of 80 elements of the list item component, which is a component that waits for three milliseconds, and then returns an LI element with the children prop, which is essentially the text that we passed. And the reason that I'm waiting here for three milliseconds is just to simulate a component that's heavy, that takes a long time to render because it's very complex. Now if I type something into the input field, so let's say I'm going to type React conference typing, and stop typing now, and then I can see the value in the input field and in the list. So if I do that again, React conference, stop typing now, and then I see it. So I hope that you noticed that lag that I had. It was like about a second or two between the moment I finished typing React conference into the input field and the moment I saw the value being populated in the input field itself and being rendered on the list. And that's because when I typed in the value, I had another component, the my slow list component that rendered as I was typing it. And I'm sure that like most of you at least, I've seen this type of issue happening in your applications where you have like a laggy input field because there is another complex heavy component that needs to be rendered based on the value that you have in the input field or something similar to that. So let's take a look at our app just to like understand why this is happening. And we're going to look at it in the form of a tree, connecting all the components and see what's happening. So the stack reconciler is the implementation powering React 15 and earlier. I won't go too much into details about how this algorithm works because we're here to talk about the Fibre algorithm. But what's important to know is that, for example, if the state of app has changed, React will traverse this component tree recursively, asking each component the way what are you rendering to based on that state change. Then based on the result of the render function, it would create a virtual DOM and updated DOM with that result. So this reconciliation algorithm is a purely recursive algorithm. An update results in the entire subtree being re-rendered immediately. While this works well, it has some limitations. You can see here that the input element in the blue one, and that's the one where fast response is important to us. We want the user to see what he or she types right as he or she types it. However, since the typing updates the state of the entire app component, everything renders including that red slow list. And that's why everything seems so laggy. So what is really wrong with a stack reconciler? I have a quote here from Andrew Clark, one of the team members of the React core team at Facebook. In UI, it's not necessary for every update to be applied immediately. In fact, doing so can be wasteful, causing frames to drop and degrading the user experience. Now with the old reconciliation algorithm, we couldn't break the work into incremental units. If React was going to walk the entire tree of components synchronously and perform work for each component, it may run over 60 milliseconds available for an application code to execute its logic. Now what do we mean when we refer to 60 milliseconds and why is this a problem with the recursive approach? Well, typically for a video to feel smooth and instantaneous to the human eye, the video needs to play at a rate of about 30 frames per second. Anything higher than that will give an even better experience. And this is actually one of the prime reasons why gamers prefer a higher frame rate for first person shooter games where precision is very important. So having said that, though, most devices these days refer to their screens at 60 frames per second. Or in other words, with 60 frames per second, a new frame is displayed every 16 milliseconds. This number is very important because if the React renderer takes more than 60 milliseconds to render something on the screen, the browser will drop that frame and the user would get a lag experience similar to what we saw earlier. I don't know if you've ever seen a video that was created using 12 FPS or 10 FPS or 20 FPS, but it's not as smooth as 30 and definitely not as 60 FPS. Another thing that's important to note is that JavaScript is a single threaded language. And because JavaScript code is executed in one thread, only one line of JavaScript can be run at any given time. The same thread is also responsible for other document life cycles like layout and paint. And this means that whenever JavaScript code runs, the browser is blocked from doing anything else. If React is going to walk the entire tree of components synchronously and perform work for each component, like we said, it may run over that 16 millisecond that's available. And because browsers only have those 16 milliseconds to do all the work in order to run at 60 FPS, reacting to each of those events can completely block your JavaScript application when we fail to meet that 16 millisecond budget. That's essentially when we see the content of your web application jutters on the screen. It's often referred to as jank, again, what we saw in our demo. And of course, it negatively impacts the user experience. Now you might think, why not make React faster? Well, the problem in the demo that we saw, for example, was that an update such as the user input is stuck behind larger updates, such as the complex component tree that was that slow list. That's user code. It's not part of React itself. So with everything I explained so far, we can formulate two problems that we have to solve in order to get to more responsive user interfaces. First one is that long running tasks cause frame drops and we need to make sure all of our tasks are small and can be completed within a couple of milliseconds so that we can run them within one frame. And then the second one is that different tasks have different priorities. So let's introduce concurrent mode. It is experimental and it's a set of new features that help React apps stay responsive and grace fully adjust to the user's device capabilities and network speed. So because it is experimental, things may change. It's not recommended to be used in production just yet, except for at Facebook where it is being used in production. And if you want more details, I would highly recommend checking out the official React docs. And we just noted that JavaScript is single threaded. So how can it possibly be concurrent? Well, it's mostly about conceptual threads or in more accurate terms, cooperative scheduling or cooperative concurrency. Essentially what all these fancy terms mean is that once a thread is given control, it continues to run until it explicitly yields control or it blocks. So what does it mean? Let's take version control systems as an example. Before version control systems, as you can see on the right, if we wanted to work on a feature, you had to make sure nobody else was touching the files you were touching. You had to let everyone know we were working on these files, essentially we're blocking everyone else from making changes to these files since you were working on them. And this can be thought of as a synchronous process. When version control systems came along, you would just create a feature branch, do your work and then merge back. And this can be thought of as an asynchronous process. So React Fiber essentially eliminates the need to process updates in a synchronous recursive way. Instead, it enables React to take advantage of scheduling and prioritization. And that enables us to pause work and resume it later, to assign different priorities to different types of work and reuse previously computed work or throw it away if it is no longer needed. So, for example, in our demo, React could keep the input field responsive to the user, meaning the user would see what he or she was typing right away since it would have a higher priority than the list of elements that needed to be rendered. Then when the user doesn't do anything, meaning doesn't block the main thread, React can render and display that list of elements. So that sounds cool, right? Well, let's see it in action. This is the same app that we had before. The only difference is that we imported the use deferred value hook here and we're passing the text state variable along an object with the timeout ms set to 2000. That's 2000 milliseconds, which is equal to two seconds. Now, we're passing the text state variable to our input field because we want it to be up to date with what we're typing. But to the mystolist, we're passing that deferred text variable because, well, you'll see. Now, let me type React conference again. You can't really see that, but as I'm typing, I'm seeing the characters being typed into the field. But the list is being lagged behind when it comes to what it renders. I'll do it again. See finished typing? And now the list is slowly catching up on the rendering, right? So the use deferred value is a hook that wraps a prop or state value and receives the maximum deferred time. It essentially tells React it's okay for components depending on this value to be rendered at a later time. And it's commonly used to keep the interface responsive when you have something that renders immediately based on user input, just like in our demo here. So for example, with this code, it essentially says we need to show the text in the input field as soon as the user types it. We need to see exactly what they type. But when it comes to the list, it's okay if it takes up to two seconds to catch up on what it needs to render. So let's understand what a Fiber object is. Not the algorithm, the object. So a Fiber is also a JavaScript object that contains information about a component, its input and its output. And it also corresponds to an instance of a component. There's quite a lot of fields on FiberNode, so this is not a comprehensive list by any means. But just to give you a general idea, you can see there's information about the component children, if it has any, siblings, pending updates, type, pending props, pending state, work priority, and a bunch more. So when it comes to the Fiber algorithm, it has two phases, reconciliation and commit. Now the reconciliation is interruptible, meaning we can pause and resume it whenever we want. And the commit is not interruptible, meaning once we start it, we can't stop it. We have to let it finish. So during the initial render, each React element that's being returned from the render function call is being converted into a Fiber. And when a React element is converted into a FiberNode for the first time, React uses that data, that Fiber that was created from the call. Essentially, the React element is being converted to a Fiber, and then that Fiber is being put into a tree that is called current. So here we can see a specific example for the input element, but this, of course, happens for all the other nodes in the current tree as well. React element being converted to a Fiber, which is being used to construct the current tree. And this tree is essentially, it reflects the current state of the UI that needs to be rendered. And it will be rendered, right? In the first render when we load our application. Now let's talk about updates. When React starts working on updates, so for example, a state change, it builds a work in progress tree that reflects the future state to be flushed to the screen based on that update. So as you can see in this case, it has the same fibers as the current tree. But let's say with this input element here, we can see there is on the left with the current tree, there's an effect tag of zero, meaning there's no update and the value is an empty string. But as we type, so let's say if we type a lot, the first letter is E, we're going to get a Fiber with an effect tag of four, meaning there's an update pending and the value that it's going to have is E. So all state and props update work is being performed on Fibers from the work in progress tree. As React goes through the current tree for each existing Fiber node, it creates an alpha node and all of these nodes constitute the work in progress tree. The reason we need the work in progress tree is because we don't want to make changes to the DOM while we're computing the changes, unlike in the stack reconciler. Again, this slide just shows an example of how our input element is updated, but the same happens for all of the other Fibers as well that have any updates. So the work in progress tree contains all of the most up to date states and props for each component, but it hasn't yet been flushed to the screen. But wait, does it contain all of the most up to date information on each component? Well, not really, because if you remember, in our demo, we told React it's okay to delay the calculation of the slow list by at most two seconds. That means that other calculation work, like for our input element, is going to be prioritized and executed by the main thread, while other lower priority work, which is the mySlowList component in this case, will be queued for later because it has a lower priority. Only after the high priority work is done and displayed on the screen, only when we're done typing, because that's the high priority work, then React will move on to the lower priority work and calculate it. And again, that's the mySlowList component. So React has processed the app component and its children, except for mySlowList, and now it's done with the render phase, the reconciliation phase. On the right is the new tree that needs to be flushed to the screen. It can be processed immediately after the render phase or the reconciliation phase. It's the same thing. Or picked up later when React is given time by the browser's main thread. In our case, since the two seconds haven't passed yet, let's say, React has time to commit these changes to the screen. And of course, these changes being our typing into the input field. Now, one of React's core principles is consistency. React always updates the DOM in one go. It doesn't show partial results, right? The work in progress tree serves as a draft that's not yet visible to the user. So React can process all components first and then flush the changes to the screen. It's important to understand that the work during this first phase, the reconciliation phase, can be performed asynchronously. React can process one or more Fiber nodes, depending on the available time, then stop to stash the work done and yield to some higher priority event, if there is any. It then continues from where it had left off. But sometimes, though, it may need to discard the work done and start from the top again. These pauses are made possible by the fact that the work performed during this phase doesn't lead to any visible to any user visible changes, like DOM updates. In contrast, the second phase, the commit phase, is always synchronous. And of course, that's because the work performed during this phase does lead to changes visible to the user, like DOM updates. And that's why React has to do it in a single pass. You cannot pause, show partial results, and resume it. It has to go in single pass. So the commit phase. Activities like mutating the DOM or calling lifecycle methods are considered effects and they are stored in the list called the effect list. In our example, the properties of both input and app change, so their corresponding effects are stored here in this list. And React essentially in the commit phase would iterate this list and commit the changes to the DOM. So if you remember the input field, we need to change it because we're showing something in that input field, right? But then also the app state, we need to change its state as well. So both of these components, those elements, have effects waiting to be committed to the DOM. This also means after we're done, like after all this work is done, the work in progress tree has a more up-to-date version of the state of the app, right? So React also swaps the root pointers of the current tree and the work in progress tree, thereby effectively swapping the current tree with the draft tree it built up based on the state update we had. So to conclude, if you remember at the beginning of the presentation, I formulated two problems that we have to solve in order to get more responsive user interfaces. The first one was that long running tasks cause frame drops. And the second one was that different tasks have different priorities. We addressed these by using the use deferred value hook, which takes advantage of the Fibre algorithm and essentially it assigned a different priority for each task and solved our frame dropping issue we had at the beginning of the presentation. It's also again important to mention that these concurrent mode features are not yet available in the stable release. And in order to use them, you'd have to install an experimental build of React, which is of course not recommended to use in production since there are still some bugs and missing features. So Fibre will make React apps better in the near term by allowing higher priority updates to jump in front of low priority updates. And it does this by breaking up the work into small units of work called Fibres, which could be paused and resumed later. There's a lot more to talk about and mention when it comes to how Fibre works. So if you are interested in Fibre and all the experimental features of concurrent mode, I would highly encourage you to read more about it. The React official docs are a great resource as well as looking into the React code itself. I hope this presentation gave you a good idea of what's possible with Fibre and got you a little bit excited for the future. I personally think that the combination of Fibre and concurrent mode delivers a very bright future for React where we as developers could achieve things we couldn't have before and by that enable a better user experience in our applications. With that, I would like to thank you all for listening and enjoy the rest of the conference.


Elad Tzemach

We Don’t Know How React State Hooks Work 

Hi, this is we don't know how React statebooks work. My name is Adam Klein, and I'm broadcasting from Tel Aviv, Israel. So let's take this code, which uses a state that's initialized to zero, which is a counter. And we have a button that has an onclick event handler. And the onclick event handler calls set counter, which is the set state function, and passes in an update function, which increments the value by one. Let's see what happens when we call set counter. Now you probably know that React manages the state of the hooks for us outside of the component. And what I used to think that happens is that we call set counter. React takes the current state of the hook, which is in our case zero, calls our update function, which returns one, and updates the state of the hook to the new value, which is one. And then re-renders our component. And the render function calls use state, which gets the new value, which is one, and the component re-renders. This is pretty straightforward, except that it's wrong. So let's see what React really does. And this is a simplified version. So in fact, every hook has its own update queue, where React keeps all of the pending actions to this hook. So when we call set counter, React just adds the update to the queue. It adds an action. What is the action? Whatever we passed inside set state, which could be either a function or a value. Or in case of reducers, it's the action that we dispatched. And then it just schedules a re-render, which means it flips some flag that says this component needs to be re-rendered. And there might be more updates to this hook or other hooks or hooks in other components. And eventually, React decides to re-render. And then it re-renders all of the components according to their order inside the tree. So when does this React decide to re-render? We'll talk in the last part of this talk. So eventually, we re-render. We call use state during render. And only then, during render, React will perform the updates inside the queue of this hook. So it takes the first action, gives it the previous value, gets back the new value, which is 1. And if there are more actions, continues to the next action and performs them one by one, and then goes to the next statement in our render function. So this is called a lazy update, which means React only does the work when the result of the work is needed. And everything I say about use state holds for useReducer because, in fact, under the hood, useState uses useReducer. So it's the same mechanism behind the scenes. Now you might be wondering, what about renderBailout? So if React only calculates the new state during render, how can it bail out of render if the new state is different than the old state? So in this case, we have a state that starts from 0. And if we update it to 0, you would expect React not to re-render our component. So it turns out there's actually another step that sometimes React decides to take for this optimization, which is to eagerly calculate the new state immediately when we call the setState function. And then if the new state is the same as the old state, it doesn't schedule a re-render. And if they are different, then it continues normally, but it caches the result of the calculation inside the update queue so we can use it later when we render the component. So the cycle continues, we get to the new useState function, React performs the updates inside the queue. And if the action already has a cached result, it uses it and updates the state of the hook. So we have these two modes, lazy or eager. With lazy, React only performs the actions when they are needed. And with eager, they are performed immediately. And lazy is used to save redundant calculations and postpone them. And eager is used to bail out and save redundant re-renders. And the final part is, when does React decide to re-render? So when you have event handlers, for example, on click, React runs them inside something they call a batch. And inside the batch, all of the updates are queued. So in this case, we have two calls to setCounter, both of them are queued. And when the function completes, the batch is over and React re-renders. So in this case, we have two updates in the queue and one re-render. And what about async event handlers? With this example, the function completes before the async operation is done. So in this case, when we get to setCounter, we're already outside of the batch, which means that it will trigger a re-render immediately after calling setCounter. So in this case, we will have two calls to setCounter and two re-renders of the component. And now there are ways to manually invoke the batch, but we won't talk about them during this talk. So in fact, we are done. I hope you enjoyed. I hope you learned something new. Remember that you can always open the source code of React Hooks. If you find it hard, you can contact me and I'll help you. And if you have any other questions, I'll be happy to answer them in the Discord channel. And I hope you have a good conference and stay safe and hope to see you all face to face soon. Bye bye.


Road to a Better UX with Suspense and Concurrent UI

Hey everyone. So today I'll actually gonna be discussing how we can take UX to the next level with React, Suspense and Concurrent Mode. So before starting for the ones who don't know me, so hey I'm Nikhil, I'm a software engineer at Postman. I actually handle stuff around design systems, Postman on the web and Postman as a platform. You can actually find me on Twitter, on GitHub. I actually love to talk about design systems and performance in general. So come say hi, it's actually gonna be a great chat. So before diving in, let's actually cover what are gonna be the key takeaways of this lightning talk. So in this talk, we are actually gonna discuss how we can actually have more control over the loading area, which means how we can actually control where exactly do we want to show a loading shape. Is it gonna be the whole page or can we actually control our loading on the UI that's gonna be asynchronous with the API called Suspense. Secondly, we are gonna see how we can start prefetching our data or our screens in background while we are right now in some other screen with the magic of Concurrent Mode. And thirdly, we'll actually see how we can actually reduce that janky spinner experience with actually the users for our faster connections actually face with a loading indicator, which just comes and goes in a flash for them using a hook called useTransition. Okay, so with that being said, let's actually deep dive and thread this road to a great UX together. So I'll actually switch to a small demo of a Twitter dashboard that I actually have here. So this dashboard actually shows me a profile section, which shows my name, my designation. It has a small about me section, which actually displays a small description around me and the work that I've done. And there's a tweet section which actually just shows what is the current tweet that I tweeted. Just don't try to go check the Twitter, it's just something that I've contracted. And there's an extra button which I click and then I just see another tweet. Okay, so far so good. Now let me actually just go and switch to concurrent mode on version of this app and let's just see how we can actually improve the UX right now. So let me just refresh and I go to this about me section. And if you see I have this nice big loader on my whole tab. And because of like, even if I have just small content inside my tab, which is my description, which was right now asynchronous, but I'm actually loading my whole tab and I'm actually showing a spinner for this whole section, which is actually not a great user experience. I could actually render my static content as it is, regardless of the fact that my description is running or not. So moving on to how it is right now coded, let's actually see how we are actually written this up in our code. So we have a suspense block inside this block. I have some static content as a small div. So what if I could actually take this particular div out and render this inside or outside the suspense block. And this is actually how suspense actually gives you a fine grained control by defining a small sort of a boundary. And it lets you control over what exactly do you want to show you're loading upon. So let's say this, I refresh this app, I go to my about me section, and now my static content is already there for my users to interact with while my description was still loading. Right. Okay, so, so far so good. And it's simple. Now, let's actually try to uncover and see how concurrent mode can actually help us in removing some of those more loaders. So on the left side, we actually have a synchronous synchronous mode of that app. And we actually right now fetch stuff while we are going to a screen. So in the left, and I click on this about me section, I see a nice loader, and then I start loading that stuff. But since concurrent mode is something which switches tasks into priority, I can actually start fetching my description and my tweets, actually, when I'm right now on the profile page, and I can actually start rendering things in parallel while I'm on this profile. So what do you think that what would happen if I just go to the about me section, and I just click on this, would I see a loader? Let's apply it after we find out. So I click on this, no loader, no spinner, it just appears that it was actually right now there, right? I click on this tweet section, no loader. But on this left hand side, I click on this, and it now starts to fetch stuff while I'm now on the screen, right? Okay, so two spinners have now been mitigated. Okay, now, let's actually uncover another use case, right? So what happens when I click on this next tweet button? I actually see a loader, and it just comes and goes, right? I just see it in a flash. And this is something that our faster connection users face, right? And the purpose of this loader is not defeated, because the small milliseconds of time would be something that you would actually skip that loading state, right? And you would actually just let your screen be as it is rather than just showing the loader. Now let's actually try to remove this loader itself and use a cool hook called use transition. So I have this component right here, which is tweet list. And let me just comment out this line, which is called use transition. And what it actually asks me to give it is a timeout in milliseconds. Now what does it actually mean that React will actually switch my or skip my loading state if my data actually comes within this two seconds of time. So if I check this on click logic of my button, right, this is actually the logic where I actually set my state and enable loading state with suspense. Now what if I could actually just take all of this, I copy and use start transition, which actually has a function and I copy and paste all of that stuff inside. Okay, and the start transition actually takes care of all the stuff that if the data actually arrives within these two seconds of time, just in the loading state. Now let's actually use this is spending billion value which use transition gives us. So let's just say this button to actually see this. I save it. Now let's actually see how things happen in synchronous and concurrent mode, right? So I click on the street section. Now I'm seeing a loading state for the first time, click on this button in synchronous mode. And I'm right now seeing a loader which is not really qualified. So let's actually see what happens when I switch to concurrent mode. So with that use transition hook, I can actually skip that loading state now, right? So I click on this next week. I don't see a loader, just stay on it as it is. And then the tweet appears in a flash. Let's actually see one more time. I click on this no loader, and the tweet appears just like a flash. And it seems that it just all happened in an instant, right? Okay, so far so good. And I think we have actually made some good improvement and progress in terms of a good UX, right? So far so good, you guys are awesome. Now you all might be tempted to think that, hey, this is a super cool API, and let me just use suspense and concurrent mode and tell my managers and technically said, hey, let's use this API. It's awesome. And this is something that actually Facebook and React itself might not be in favor of right now, because suspense for data fetching and concurrent mode are something that are right now experimental. And the Facebook team is right now still looking for more feedback since the API is still expected to evolve and can be error prone right now since it's experimental. So you might actually want to fiddle with these APIs in your personal side projects, but thinking of something that is enterprise is not something that you would actually want to do, right? Since things can be error prone. Okay, on a side note, we are building great things at Postman. So if you actually like to be a part of our journey, please come say hi and visit us at our careers website, we'd like to connect and discuss things forward. So with this, I'd actually like to end my talk. A big thanks to all the organizers and the sponsors for who are actually working so hard to making this conference a great success and all the speakers and at the last but not the least, your audience, you guys, you guys are great. I had a great time discussing my thoughts with you, with all of you. So thanks a lot.


#advanced