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

Hey everyone, I'm Charlotte, and today we are gonna defy the laws of hooks together. A few months ago, the React Core team made a proposal to ask the community its opinion on the idea to add a new hook, the Use hook. A React only version of Await that unwraps promises, allowing us to fetch a synchronous data and use it directly into our components. I'm not going to be dwelling on this hook today, but there is one thing about this hook that I'm interested in. Use would have a special ability. We would be able to use it conditionally. What? How is that possible? There are only two rules regarding hooks. Rule number one, only call hooks from React functions, so function components and other hooks, and rule number two, do not call hooks conditionally. Only two rules, and this hook would be exempted of like half of them? It gets worse. In the proposal, we then learned that use would not only be hindering promises, but other stuff too, like context values. We would be able to read context values with use, just like we do with use context.

So let me get this right. This means that we would be able to read context values conditionally, and actually, we've then learned in this tweet from Andrew Clarke that we already can. We already can call use context conditionally. But why? Why can use context be used conditionally, while other hooks can't? That's the question we're going to try to answer today.

To understand why use context can be used conditionally, we'll first need to understand why other hooks can't. And to understand this, we'll need to understand how hooks work. Where is a hook's data stored? How does React keep track of our data through time and render? To understand the difference of use context, we'll first need to understand React. So let's begin with this first question.

Where is our hook's data stored? Where is our component data stored? When we build our app for the first time, React is going to build this virtual tree made of our React components. This tree is called the fiber tree. The fiber tree keeps track of the React components that make up our app. And from this tree, React is going to inject our HTML elements into the DOM to display our application on the screen. The fiber tree keeps in memory through time and re-render information about our components, their data, their props, and their states. This way, when the re-render happens, React knows which elements should be—may have been changed, which ones should be rendered, and which information should be updated in the DOM.

So the first time we build our app, React creates this fiber tree. Every time we instantiate a React component, React adds a node into the tree. And such a node is called a fiber. Let's take a look at one of them. Let's take a look at one fiber at this greetings component. When we instantiate greetings, we're using this JSX syntax, and JSX is actually just syntactic sugar and is equivalent to the call of this JSX function, or create element up to React 17. And this JSX function, when it is executed, will create, we add, a new fiber into the tree. So when you instantiate a component with this JSX syntax, you actually add a node into the tree. You create a new fiber.

Now, what does a fiber actually look like? Well, a fiber is just an object that holds information about one component. So if we look at this greetings fiber, we have its type, we have its props, props data, I kept in memory inside every fiber, along with a bunch of other states and flags for React to keep track of, and finally, we have its position inside the fiber tree. Speaking of the fiber tree, let's see how it is built. Let's see what happens at first runner when our fiber tree is built. We are going to go through our code, and every time we instantiate a React component with this JSX syntax, React is going to add a fiber into the tree.

So first off, we have this app component that has the username in this state that it passes to this greetings component, which displays it into a paragraph, and finally, we have this button that we can click to change our username. And here we go.

We have built our fiber tree. Now what? This tree is still virtual. We haven't displayed anything on the DOM yet. So what React is going to do is it is going to inject our components into the DOM, but not all of them. Some of these components are pure React functions. This greetings component, for example, it's a pure React component. It does not exist in the DOM. It's not an HTML element. So what React is going to do is it is going to go through our fiber tree and every time it encounters an HTML element, it is going to inject it into the DOM. So our paragraph and our button. And now our application is live on the screen.

So our components data, our props, are kept in memory inside every fiber. Now, what about hooks? We are here to talk about hooks, right? So let's add a second state here. Where are those two values stored? Well, you guessed it. Hooks values are kept in memory inside each individual fiber as well, but not just in any way. Hooks values are stored inside a link list, where every value points towards the next one. These values are then read by the hooks in the order in which they're called. One thing you've got to understand here is that this function component, app, is just a function. It does not retain data. UseState does not retain data. The fiber does. When you run the app, you execute this function and you pass it the values that were stored in memory inside the fiber. So let's run the app for the first time. Let's build our fiber. We run the app. We are going to be writing this. This useState will be writing that default value in the fiber in the order in which they're called. So first off, we'll have name, which is going to be writing in the first element of the linked list as it's empty till now, Rachel. Then we have age, which is going to be writing into the current element of the linked list, .next. So the second one, 29.

Now what happens after render? What happens if we click this button right here and change our first state, our username? We are going to render. We are going to execute app and to pass it the values that were kept in memory inside the fiber. So first of name is going to be reading into the first element of the linked list and age into the second one. Can you see on this schema why you can't call Hooks conditionally? Hooks rely on the order in which they are called. So if at the next render you add or remove a hook, you change the order and the data you get isn't the good one.

Let's try to do it. Let's try to call this name state conditionally based on this first Boolean value which is originally equal to false. Let's render app for the first time. So first off we have shuname which is going to be writing false into the first element of the linked list. And we don't pass this condition, so we move on to age which is going to be writing 29. Now what happens if we click this button right here and change our first Boolean to true? We will render app and we pass it these two values. So first off shuname is going to be reading true into the first element of the linked list. Then this time we pass this condition, so we have name which is going to be reading 29. So yeah, name is going to be 29 and then we have age which can find its value anywhere and get us off. We've got this error that you've probably already encountered in your lifetime as React developer. Hooks rely on the order in which they're called. They're all interdependent in their linked lists. This is why you can't use them conditionally.

Now what about useContext then? Why can useContext be used conditionally? Let's twist our example a bit and use provides our username into this context value. The answer lies into our fiber tree. So let's build it. First off we have this context objects, then we have app which still has the username in this state that it passes this time in props to this context provider. Below the provider we have greetings which is a context consumer now. It reads the context value from the username value from the context and it passes it to this paragraph. And finally, we finish up with this button that we can click to change our context value.

Can you see on this schema why useContext can be used conditionally? Let's add a second state here. Hooks values like useState or useEffect read and store their value inside the linked list where hooks are all interdependent and where others matter. useContext on the other hand, reads and stores its value inside a context object that is located outside of the tree, outside of the linked list. useContext isn't related to other hooks the way useState is. So you can call it conditionally all you want. It just won't affect other hooks.

And that's actually something you can see in the code as well. Take a closer look at the code. See when you call useContext, you're passing it in arguments, the context object. You're telling it, go check out your value right here in this very object. It's hard-coded. useState on the other hand, does not receive any hard-coded key variable to find its value in. All it receives is the list of values of all of the hooks of the fiber. And this useState is just like this one. There is no identifier to differentiate them. So how does it know which one of these values belongs to it? It relies on order. That's the implementation that was decided. So this is why useContext can be used conditionally. This is why useContext is different.

But something still seems to be missing. How does this work exactly, right? The context value is located inside this object. But if this object is located outside of the tree, how is it updated? And what actually is the role of this provider here? In order for our demonstration to be complete, I'd like to go a little bit deeper if you'd like, and to really understand how a context value is updated, how a context value works underneath.

Okay, guys, the next couple of minutes are going to be quite intense. To understand how a context value is updated, we'll first need to understand how any regular value is updated. So we'll get some theory here on React's rendering behavior. So bear with me. All right, how is a context value updated? Let's click our button right here and change our context value. Let's see what happens. We are going to rerender. We trigger a set state. What is going to happen is we're going to calculate a new version of our fiber tree that corresponds to the change that we've made to our new state, our new render. Once it's done, React is going to compare this new tree to the one of the previous order and apply the differences to the DOM. But when we calculate this new fiber tree, we don't actually render every single component of our app that could be inefficient, only the ones that may have changed. Let's see how this calculation process goes step by step.

So we click on this button right here to change our context value. We are going to change to trigger a set state. We are going to render. At this point, several things happen. First, as we said, we are going to duplicate our fiber tree. We are going to update this new fiber tree to correspond to the change that we've made. But until now, it's just the same. It's just a copy. Second thing, we are going to flag the fiber that holds the state that was just changed as needing to render. So to this app component, this app fiber, we are going to add this small render flag. And finally, we are going to traverse our tree. We are going to visit every fiber. And for each of them, we are going to wonder, should we render these components? If we do, we will render. Otherwise, we bail out. We wait, quit.

We don't render. And we begin at the top of our tree with the first fiber app. So let's use this small work in progress flag just to keep in mind which fiber we are currently visiting. So app. Should we render app? There are two criteria for a component to be rendered. And if it matches either one of them, we do render this component. The first one being being flagged for a re-render. And app was flagged for a re-render. So fair enough. We re-render app. Let's add some color in this schema. Let's put in blue the fibers that were re-rendered just to keep it in mind. So we've re-rendered app.

What does this mean? It means executing its function components. So we execute app and we pass it the values that were kept in memory inside the fiber. So first off, we are going to read the latest username value that was just changed. And then we're going through all of these JSX. And here look. Look at this greetings component, we're using the JSX syntax here. And remember JSX is equivalent to the call of this JSX function which creates fibers. So what this means is in our new tree for this greetings components, we are going to completely discard the previous fiber and to add a whole new one. This is a new object. And something, yeah, let's put it in orange. New fibers are in orange just to keep it in mind. Something you've got to notice here and it will be useful later is that as we're creating a new fiber for greetings, we're creating a new props object as well. This is a whole new object. It will be useful later. So as we're rendering app, we are going to create new fibers for all of the components that it instantiates with this JSX syntax.

So our provider as well to which we are passing the latest user name value in props and our and we are done with app. So we can move on to the next fiber, our context provider. Should we render the provider? Well, it was not flagged for render but there is a second criteria to be rendered and it is based on the props value. We are going to compare these props object, the props object of the fiber of the new tree to the one of the previous tree. We are going to compare these two objects through shallow equality and if they're equal, we don't render otherwise we do. And in our case, they're different. So we render the provider. So we execute this function component but that's not all. You see, this component is kind of special. It's not just a regular function component. It's a context provider. So, it does other stuff too, like updating the context object value, based on the value it got from its props. So the provider updates the context object value and we're done with the provider. So we can move on to the next fiber.

Greetings, should we render greetings? Well, it was not like for render but has its props changed? Well, actually yes, it has. I know, two empty objects, they seem very alike but this is a different object. So when we created a new fiber for greetings, we created a new object for these props as well. It holds the same, no, different reference, if you may. And in JavaScript, through shallow equality, remember that empty object equals empty object is false through shallow equality. So in our case, these two objects are different and we do render greetings.

So we execute this function components. We read the latest username value from the context object and we create a new fiber for the paragraph to which we pass the new username value. And we're done with greetings. So we move on to the paragraph, which is rendered, because its props have changed, just have four greetings. And we move on to the button, which is rendered as well. And we're done building our tree. Now, React is going to compare this new tree to the one of the previous order and apply the differences to the DOM. And now we're done. This was kind of mechanical. So let's take a step back from this. There's one thing or two that I'd like to discuss together. First about React and then we'll be talking about context.

About React, one small disclaimer. It isn't entirely true that we do have these two trees. In reality, there's only one. And every fiber holds on to its whole history of states. But I just find it easier to think of it as two trees. And I mean, it's my mental model. So if I want to have two trees, I'll have two trees. Second thing still about React. There's one misconception that I had about React that I wanted to share with you. I used to think that the source of truth, to know which components may have changed and which one should be rendered was the code. But it isn't. The fiber tree is.

I used to think that when we rendered app, the fact that we are calling this greetings component this way meant that we would be executing it right away. But that's not what's happening. What's happening is when we render app, when we execute this line, we create a new fiber for greetings. And then we're traversing the whole tree. And later on, when we're visiting greetings, React is saying, oh, its props have changed. We should render that. And only then do we execute these lines. The source of truth is the fiber tree.

Now in your daily life, I know you won't be drawing fiber trees. So what you can remember, what you can take away from this is when you're under—when the component is rendered, all of the components instantiates will get rendered as well. Now about contexts. This is actually how contexts work. We change the state value which regards set states. The provider is rendered. It updates the context value—sorry, animation problems. It updates the latest context—the context values—the context value from the context objects. And then all of these components are going to get rendered in Cascade and this gradient component is going to be reading the latest context value from the context objects. But actually we are not quite done yet. This does not actually represent a real-life usage of context. In real life, the first components located just below the provider hardly ever is a context consumer.

In real life, it looks more like this. We add up a few extra components between the provider and the first context consumer. Now in this case, if we take a look at these A and B components, do you think that they will get rendered as well if we change our context value if we click on this button? Well, actually yes. If we click this button right here, we are going to render app. So app, when it is executed, will create a new fiber for A. So A will get rendered. So it will create a new fiber for B. So B will get rendered and so on and so forth. All of these components are rendered in Cascade. But I mean that's too bad.

We have rendered because we changed the context value but A and B don't depend on the context. They haven't changed. We should not render them. That's too bad. And I mean when you call useContext, you're trying to call it as low as possible in your tree, as close as possible to where you actually need it. So if we can, it'd be kind of nice to avoid rendering all of the components located between the provider and the context consumer.

So how can we achieve this? How can we not rerender A and B if we change our context value? Well, one thing that I had already heard before is to memoize the first component located just below the provider. This way, we memoize this component. This way, we stop the propagation of render. This should work but actually, there is another way to achieve this, which is even closer to a real-life context usage. Can you guess what it is? It is to extract your provider into its own custom component and to pass the rest of the tree as children prop. This way, when we change our context value and auth provider is rendered, when auth provider is rendered, this A component that is passed as children prop won't and we will stop the propagation of render.

Let's make the demonstration real quick. Let's click on this button right here and change our context value. We duplicate our fiber tree, we are going to flag the component that holds the state as needing to render. So this time it's not app anymore, it's this auth provider custom components. So we flag auth provider and we begin traversing our tree. We begin with app, should we render app? Well, it was not flagged for render but has its props changed? Well, actually no. This time, this props object is the same as this one. When we duplicated our tree, this tree is the shallow copy of this one. It's a direct copy of this one, so this props object is a direct copy of this one. They hold the same reference if you may. In JavaScript, this time through shallow equality, these two objects are equal. So we don't rerender app. Did you notice? It's the first component for the last 10 minutes that we don't actually render. It feels great. All right. Let's move on to the provider. It is rendered as it was flagged, so we execute it. We get the latest username value and we create new fibers for the provider and the button.

But what about this children prop? What about this A component that was passed as children prop? Should we create a new fiber for it? Well, actually, no. The reason why we're creating a new fiber for a button is because of this JSX syntax which is equivalent to the JSX function which creates fibers. But here, children is just a prop, it's just a variable. There's no JSX here, so no reason to create a new fiber for A. So no new fiber from A and we are done with the provider. We can move on to the actual context provider, which is rendered as its props have changed. It updates the context value and we move on to A, which is not re-rendered either. You see that just like for app, this props object is the same as this one, so we don't render A, nor do we B, nor do we greetings. But now we have a problem.

Greetings is a context consumer. We want it to get rendered to read the latest user name value, otherwise our app does not make sense. We want greetings to be rendered and actually it will. The provider is going to make sure of it. There's something I didn't tell you. Let's roll back to when we are visiting the provider. We said that when the provider was rendered, it would update the context object value, but that's not all it does. It is also going to ensure that the context consumers are going to get rendered. It is going to go through all of the fiber that are located below it and flag the context consumers as needing to render. It has this information inside the fibers because when a component is rendered, if it uses a context, use context is going to write this dependency towards the context inside the fiber. So AuthProvider, our context provider, is going to flag readings as needing to render. This way, even if a component is memorized in between and the propagation of render is stopped, it ensures that the consumers are rendered. And you can see that I didn't lie. This A component did not get rendered when AuthProvider was rendered because it was passed as this children prop. So actually, extracting the provider into its own custom components not only leads to a better separation of responsibility. It also ensures that all of the components located between the provider and the first context consumer don't get rendered.

And this is actually, oh yeah, sorry, one last thing. Once the first context consumer is rendered, of course, if you add up a few extra components below it, all of them are going to get rendered as well. And this is actually how context works. And you can see that the role of the provider is absolutely crucial. It is going to both update the context object's value inside the context objects and to ensure the consumers will be rendered so that they can read the latest context value from the context objects.

With this full picture of how context works, we can then confirm that indeed, use context can be used conditionally. It does not interfere with other hooks. So this is why use context can be used conditionally. And that's all I wanted to tell you about use context, this Curious Hooks.

Do I have one last minute to make a disclaimer? You have one last minute to make a quick disclaimer, go ahead. Thanks. Just wanted to say don't do it. Don't actually call use context conditionally. It's better for young girl developers to keep it the same way as others to make sure they are not lost.

And also, one quick question. Do you think that there may be other hooks? Is use context the only one? Remember, the use hook with Octobot? We said that we would be able to use it conditionally. Why is that? And yeah. Thank you so much. Here are some resources if you want to keep diving and keep building your own mental model of threat rendering behavior. That was awesome.