Deep Dive on React Hooks Architecture

♪ Hello, everyone, and welcome to Deep Dive on React Hooks and Architecture. My name is Daniel Espino Garcia, a software design engineer at Mattermos. So what is Mattermos? Mattermos is an open source collaboration tool focused on mission-critical scenarios, but that is not what is important for this talk. The important thing for this talk is that both the mobile and the web app are written in React, and they use mostly functional components. So, yeah, that's what we use.

And why am I talking about this? Well, I'm an engineer. I like to break things and see how they are inside. And with the magic of open source, I can do that with React. I can go directly to the source code and see all that magic around hooks, about how functions can store a state and stuff like that. How does all that work? So I was curious about it. I researched it and I made a talk out of that.

So before we start, all the rebel bug images during the talk are AI generated. That's why they are not the most consistent thing. I have no relationships at all with the React team. I am just a guy that is looking into the code and getting to conclusions. So I don't know the exact reasons why things were done one way or the other, and I may be understanding things wrong from the code. So everything I've shown here is based on what I found in this repo, in the React repo. And finally, at some point, I got a stack and I had to look for help outside, and I found this blog post that was really interesting to understand how all the fiber thing works. And that was able to get me back on track. But, well, without further ado, what are we going to see? Well, we are going to see, our train is going to go from the component. We write our function component to the render, how it gets into the screen. But in order to do that, we have to get a longer path. First of all, we have to understand what is JSX. We understand what is JSX, we will have to understand what is React element, then what is a fiber. Then we will have a better understanding of what is our component, which will lead us to understanding hooks, which will lead us back into fibers and how all that renders. So let's start with that. What is JSX? JSX is just writing HTML inside JavaScript. And what is all that? It's just syntax server. The transpiler handles all this. And with a tool like this one, you can get the result.

And the result is a lot of React.createElement. So as you can see, your function, what it does is do a React.createElement and return that. That's all it does. So, interesting thing. You must import React. Because if the transpiler substitutes things to React.createElement, it needs React to be in the context. That's why you get so often these errors like, hey, you are in JSX file and you haven't imported React. You have to import React. This is why. Actually, there's a new runtime that, in theory, gets rid of that. But, yeah, I haven't looked deep into that.

So we have this React.createElement. That's what our function component is returning. But what is actually a React.createElement? So if we go to this part of the code, we see that React.createElement is just an object. The component itself is not even called. The component is going to be stored in type. So type will store a function, our function component. So, okay, if our component is not yet called, when is my function component called? Well, okay, so we have components that just return a React.createElement. And if we go up that tree, we will get to the root.

And the root, according to a template, should be something like this, React.createRoot, and then root.render. So let's focus on the first part, on createRoot. What does that do? It creates a host root. A host root fiber. So what is a fiber? A fiber is work on a component that needs to be done or was done. That is the definition they have in the code, in some comments. So, okay, it's work on a component that needs to be done or was done. And what the host root part means? It's a reference to a root in the host system. The host system, in our case, will be the DOM. Okay. We are creating this root that has a reference to somewhere in the DOM, and then we are calling render.

Okay, and what were we passing to render? JSON, so ReactElement. This is not yet calling my function component. When is my function component called? So what render does is scheduling the root fiber. So it calls render, that calls updateContainer, that calls scheduleUpdateOnFiber, that calls ensureRootIsScheduled. That, at the end of the day, what it's doing is adding the root to a linked list. It adds the root there to this global variables, that is the first scheduled root and the last scheduled root, in order to get this linked list working.

And then the scheduler comes into place. The scheduler is another beast. You could make a whole talk just about the React scheduler. So I will keep it simple, and I will just say that a scheduler, whenever it sees that it has to do something on a root, performs work on that root, that work is divided into units of work in order for React to be able to stop the rendering at any moment, so other processes don't get starvation. So it can do things by units of work, and then begin working on a single fiber. So in order to decide what to do with that fiber, it's based on certain tags the fiber has.

So when we started the host root fiber, what it does is it sees that it's a host root, so it calls the mount children. Mount children will look into the contents, it will look into this React element, and will create a new fiber. This fiber is a function component fiber for our app component, let's say. Then the scheduler will say, hey, this fiber has that function component, so I have to call renderWithHooks. RenderWithHooks is the one responsible of actually executing our function component. And if you remember what the function component does, it returns a React element. So that is passed to mount children, and now it can mount a child for that component.

This will create all the tree, and if these children will have siblings, the siblings will also be linked at least horizontally. So that's how React creates this fiber tree. So when we have the fiber tree, React also needs to know what changed since the last render. So React stores always two different trees. The current tree that represents what is now in the screen, and the work in progress one. So when the scheduler runs again, it will start creating the work in progress tree. We'll say, okay, it has a host root, it's the same, I have the app, it's the same, I have the child, it's the same as before.

Oh, but this child no longer has siblings, so I will mark these siblings to be deleted. And then it has a child, there is the same, oh, but this image is also not there, so I will mark this to get deleted. And when it's finished, it will just substitute the current one with the work in progress one, so the next iteration it can do this all again. Okay, that is everything for now with the fiber tree. So where are my hooks? I know now that our component gets executed when it gets rendered by the fiber tree, but what, for example, when I have a useState, where is that state living? Well, let's look into that.

First of all, I'm going to use the useCallback hook because I feel it's complex enough and simple enough to give you an interesting initial approach to what hooks do. So if we look into the code on the react-hooks file, we see that useCallback, what it does is get a dispatcher and call the useCallback version of that dispatcher. Okay, that does nothing. So what is that dispatcher? Well, the dispatcher is coming from a global variable shared between different files. That is the react-share-internals. Okay. How is that assigned? Well, when you're rendering the hook, it says, hey, when you are dealing with a fiber, it says, hey, there's a current fiber.

No, then it's mount. If there is a current fiber, it means that we already have rendered that fiber. So what we need to do is update. So if you remember the two different trees, the idea is that some elements may not have a previous fiber to look into. So those will mount, and those that have a previous fiber there in the current tree will just update. Okay.

How do these two dispatchers look like? Well, they just call a different either a mount function or an update function. Most of them. There are some exceptions, but the ones that we are going to look into just decide between mount or update. So mount callback. What does it look like? Well, we have a hook that mounts the work in progress hook. Okay. And then we just store in the memory state the callback and the next dependencies. Perfect. What is that hook? Where is that coming from? Well, that hook is just an object. Again, really simple.

Memo is a state, a few other things that are needed, and a next property in order to make another linked list. So what we are doing is creating this object and adding that object to the currently rendering fiber memoized state and just create there a linked list. As you can see there in React, we are using a lot of global variables. In this case, the currently rendering fiber, the current hook, the work in progress hook. This is used to orchestrate everything that happens at the same time. Well, even if you have been told probably that global variables are evil, here they serve a purpose and they are correctly used. So, yeah.

So, yeah. They are using these global variables mainly in order to improve performance, since this is a really hard part of the code. It's great that they do it this way, even though it may be complicated for some things. But, well, let's back to track and let's see the update.

When updating callback, what we are doing is getting, again, the hook, checking the dependencies if they are equal. If they are equal, return whatever we had in the memoized state. If not, update the memoized state with the callback and the next dependencies. And that's it. Okay.

But what is this update work in progress hook? Well, what this does is it creates a new hook object, gets all the state from the one in the current fiber, and then add it to the linked list of the currently rendering fiber. So, yeah, it's a bit confusing, but let's look into a graphic example. So, we have here a piece of code at the bottom that we say, okay, I'm going to call use callback and then use memo. This is the initial state. We have a work in progress fiber. That is what we are, the component that we are rendering. And we don't have a current fiber. The current fiber is pointing to null. So, that's why the dispatcher points to mount. So, what happens now? We call use callback. It creates a new hook object, add it to the linked list, and then add to the memoized state the function and the dependencies. Then we call use memo. So, it creates a new hook object, it add it to the linked list, and add to the memoized state the value and the dependencies. And that's it. That's what happens on mount. So, let's see what happens on update. Now, the state is the following. We have the current fiber, the things that we rendered in the previous run, and we have the work in progress fiber. That is the component that we are executing right now. So, the dispatcher goes to update because we have our current fiber. What do we do? Well, we call use callback.

So, we create a new object, add it to the linked list, and then we point to whatever we had in the previous one. Let's imagine that there are no changes at all. So, we don't have to update the memoized state. So, for use memo, the same. So, it gets added to the linked list, and it gets the previous value. Again, we are not updating it because nothing has changed. And, yeah, that's what is happening on the inside.

Now that you have seen all this, you can understand the rule of hooks. If you have, for example, this case where you have the hook three that renders conditionally. So, the first render, you have hook one and hook two executing. They have their memoized state created, their hooks created, and so on. And then the next renderer, you have hook one, hook two, and hook three. So, when you get to hook three, where is my memoized state? The hook three doesn't find its memoized state and is trying to update. So, that is a problem. The other thing that can happen is this one. You have the first iteration that you call one and two and the second iteration that you call one and three. In that case, you can find a memoized state. But, hey, that's not my memoized state. That's not what I'm looking for.

Let's look into other hooks, what they do. So, useRef. useRef is the simplest one. It just stores the current value object into the memoized state and just keeps returning that object. useEffect is into the memoized state. It stores the effect that includes the creator function and an object to store the destructor function. Also, it queues the effect on the fiber. What happens then? When you queue an effect on the fiber, this effect will be called at a different moment. It will not be called just after the render.

What happens then? When you queue an effect on the fiber, this effect will be called at a different moment. It will not be called just after the render. When the scheduler is performing the work on root, it will get into a finish concurrent render, commit root, and finally, flash pending effects. That's when our effects will be called. So, yeah, it will be called after the render.

So, what about useState? useState is also quite complex because, first of all, on mount, it will store the initial state, and then will create a queue for state changes. And then will create the dispatch function in order to add things to that queue. And finally, it will return the initial state and the dispatch function. So, what does this dispatch function do? If it is on render, update it to the hook queue. And then, it sets a flag that makes it render just after the component gets rendered.

On update is when all the updates get applied. So, the updates are not applied until we actually render. And all updates are applied sequentially. That way, we then store the new calculated state to the memory state, and return the state and dispatch function. So, that's what useState does. And yeah, that's it. That's the magic of hooks. That's how these functions can store state. As you can see, the magic is a lot of global variables, a lot of linked lists, and a lot of objects living in memory. So, what is the actual cost of using hooks? Well, for starters, let's look at the CPU. For example, for useRef, it's constant order. For useCallback, it depends on the number of dependencies. And useState depends on the number of updates. So, if you have something that updates the state a thousand times between renders, that's going to be a hit on CPU, but probably nobody's doing that. Then there's memory.

For example, for useRef, it's constant order. For useCallback, it depends on the number of dependencies. And useState depends on the number of updates. So, if you have something that updates the state a thousand times between renders, that's going to be a hit on CPU, but probably nobody's doing that. Then there's memory. You have to store the hook object, you have to store the queues, the effects, you have to store the memoized state, you have to store the dependencies. Those can be many things to store the dependencies. But, well, let's see what a practical example. For example, we have a useMemo, or just passing the style like that. So, the option on the right, in theory, is better, because that way we don't have to check the height on every render. So, that's less CPU. And we don't have to store the dependency list with the height, we don't have to store the height object, the style object on the hook for returning it every single time. So, the one on the right is better, right? Well, if you look deeper, the props are still stored in the fiber, because you need them to compare the current fiber with the previous one to see if anything has changed. Also, the way style works is interesting on the inside. On the left side, you have what the DOM does, and on the right side, what React Native does.

Now, at the end of the day, when you are passing styles, it will check every single style to see if there's a difference in order to decide what style to change. So, yeah, probably that is going to take a few more loops than just using a useMemo. But, well, that's all that I wanted to share today. What did I miss? Lots of details. Also, reconciliation, class components, suspense, context, server-rendering hydration, many hooks, children reconciliation and key handling. I missed a lot of things, but, well, it's 20 minutes, and that's what we can fit here. But, yeah, there's still a lot of details to look into. But, well, we can look at that in the future.

Okay. That's everything for today. Thank you very much. Have a great day. ♪♪♪