React Summit

React Summit 2023

Speaker's Room: Charlotte Isambert

Charlotte Isambert

It’s the hooks rule number one: “Only call hooks at the top level”. But what if I told you that this rule does not apply to every hook? One of them can actually safely be used conditionally.  To understand how useContext is different from other hooks, and why it is exempted from this major rule, we need to know why this rule exists in the first place. We will build our own mental model of react’s rendering behavior, focused on how react keeps track of data at runtime: props, states, refs… and context values.

You Can’t Use Hooks Conditionally… or Can You?

React Advanced

React Advanced Conference 2022

How do you start your app on your simulator in the morning? Do you always run react-native run-ios? If so, you might be wasting a lot of time. Let’s check out together what a React Native app looks like under the hood. It will help us to be more efficient on a daily basis. We’ll identify the shortest steps to execute daily actions, like starting our apps as fast as possible (no more unnecessary compilations of native modules!), or dealing with pesky red errors that metro throws at us. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

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.
