If You Were a React Compiler

[♪ music ♪ I've been a dev for about 25 years. I'm the director of education for the SMYTH group, S-M-Y-T-H, and I've taught about 350,000 students web fundamentals in my courses on Udemy, Pluralsight, and other places, and you can find me currently on understandingreact.com for deep dives into React's source code.

And today's talk is entitled, If You Were a React Compiler. What is the most powerful tool in a developer's tool belt? Well, lots of people might have different answers to that, but I think the most powerful tool in a developer's tool belt is an accurate mental model, meaning that you have a reasonable understanding of how the tools you use work. Because if you have a reasonable understanding of how the tools you use work, you make good architectural decisions. You have confidence as you use the tool. And you're able to debug when things don't go as expected.

So in this talk, the goal is to build an accurate mental model of how the new React compiler works. And in order to do that, we're going to pretend that we're the React compiler. We're going to take an example piece of code that's slow, and we're going to try to do what the compiler does. So if we're going to be the compiler, we have to have some ground rules. What's our focus, and what's our goals? Well, we know that React by design calls the functions we give it, that is to say our components, over and over again. Now, React likes to call that components re-rendering. But really, we give React our function objects, and then React chooses when to execute and re-execute those functions. And that means that React's performance can be tied to how often our functions are called, and how much work our functions do.

So what's our goals? Well, our goals as a compiler are to minimize re-renders, that is minimize how often, how many times, our functions that we give React are called over and over again, and to skip expensive calculations if we don't need to run them. And that will improve our performance. Now, there's been some controversy online about whether React compiler is a compiler, so let's get that out of the way. In computer science curriculums, often folks are introduced to compilers when talking about converting higher-level programming languages into machine language, and that's true. But it's also always been true that there's such a thing called a source-to-source compiler. Sometimes we call that a transpiler. And that's essentially what React compiler is. Source-to-source, it takes code as an input and outputs equivalent code, code that does the same thing that our original code does, but with some extra goodies. And that's what React compiler does. So if we're the compiler, we're going to do the same thing that the React compiler does.

Now, when a program running as a compiler runs, it analyzes the text of the code. So that's what we would do. Now, in the case of an actual compiler, it might convert the text into something called an abstract syntax tree. So it might take a line of code that we write and then convert it into some kind of object structure, which can then be looped over, reasoned about, et cetera, and then output new text, new code. Source-to-source.

And then it's going to take that idea and proceed algorithmically. It's going to go through our code and make decisions on what code it's going to output. So that's what we're going to do. We're simply going to proceed algorithmically. And we'll see what happens.

What's the first thing we need to do? Well, our whole point is to avoid useMemo, memo, useCallback. So we need to prepare to memoize values. So let's start by looking at some code. This is a very contrived example, but it's a 20-minute talk. So contrived examples can be useful. So here's our contrived example. And I have some adjusted code on the right, but you can pay attention to the code on the left, and we'll move it back and forth a little bit.

So I've got a very, very simple counter. Classic example, passing to it a count and an increment function. I've got an intentionally super-slow function. There's our major problem. And then I've lifted state at the app level here, and I essentially have some unnecessary rerenders going on. What I'm doing is I have a couple of clicks to add two numbers, and that's going to be slow. And then I'm calling my counter component, which is just going to increment its own state. So it ends up looking like this. I click was 5 plus 10. It's slow. Now it's 5 plus 11. And that's fine, but notice the counter also rendered. It didn't need to. And then when I click plus on count, it again runs that slow function and then increments. So that's a problem.

Now, we have a few ways we could handle this, and one of the ways would be that we manually do use memos and use callbacks, et cetera. But we're not going to do that. Instead, we're going to proceed algorithmically.

I'm going to be prepared to be able to put things into memoization. So I'm going to drop a simple function here, and I'm going to define the concept of empty. I'm just going to make it a symbol because I don't want to worry about is it null or undefined? Is that an accurate value? I want to know that this is empty, is I'm going to have what is essentially a custom hook, C for cache, let's say, and it's going to memoize an array of whatever size I give it and fill that array initially with that representation of an empty value. And that's it.

Now, when I go to use it then, and I'll just have my reference code over here. We'll go through just a little bit. When I go to start algorithmically working through all of this code, the first thing I'm always going to do is say, well, I know I want this array of possible memoized values for this component. This component is now going to be optimized. But I'm not going to go through and add use memos literally everywhere. I'm simply going to have an array of values at the top. And what is actually happening here when I do that? Okay, let's refresh this and make sure we've got... Make sure we've got that in place. And I missed my use memos, so let's do that. And we'll just let this refresh.

Okay, so that's running, but where's the memoized values? Well, it's interesting. We can actually go get the section element created in that counter. And in the section element, I can actually get a reference, you see that there, to the node in the fiber tree that is what we colloquially now call the virtual DOM. I can go get or find that node that generated that DOM element, so let's get that. And inside that, I can go find its parent, which is called return. What's the parent of this section? It's Counter. And there it is. And in that node of the virtual DOM of the fiber tree, that is, there's an array, and there's all my empty values in the array. So the memoized value's just sitting in a JavaScript object in memory in the browser. And as React is recalling and calling over and over again my functions, it can access that piece of the node hanging off the fiber tree. It kind of looks like... let's just show this. It kind of looks like this. Whenever you use a hook, it's actually moving down the next value in a linked list. So whenever you see Use something, it actually means move to the next value in the linked list, and there's the data I need for that value, whether it's state, callback, memo, whatever it is. It just goes down that list, which incidentally is why you can't put hook calls and if statements and loops and things like that.

But there it is sitting in memory. So I'm prepared to put things into memory. And what I want to put into memory are functions, or really the return values from the functions. And my assumption is that functions are pure. That's one of the rules of React, right? That if I give a function the same input, I always get the same output, and that allows me to memoize or cache or store the value of that function when I give it the same input so I don't run the function again.

Okay, here's a question, compilers. In this simple counter function, ignoring the console, ignoring these two lines up here, are there any other functions being called in this simple example? The answer is yes. Because remember, our mental model of React, we write JSX, but what is JSX? JSX is function calls. It's not actually calling our functions, it's calling internal React functions and we're giving it function objects to call or we're giving it strings that say, call these internal functions React already has, and builds up the DOM. If I'm the compiler and I'm saying I don't want to recall a function if not necessary, then I also want to memoize the functions that the JSX is converted into. And the dependency would be the things that are passed to those functions, which we tend to call children. Those are really just an object or an array being passed in to that function call.

If I'm starting to think about this programmatically, what am I going to do? Well, I'm going to come across, let's just say we take this paragraph. I'm going to say, well, I have a value. Again, I'm just going to think algorithmically. I'm not going to think too deeply. And I'm going to check if that first value is equal to count. If my counter function is called again and it's passed count, I'm going to check if I've already stored that same number in the memoization array. And if I haven't, then I need to essentially call my function again, because there's a new count value. If it originally was count zero and I'm past zero, I already know the result, p count colon zero. But if it's one, now I need to recalculate that. And what I can then do is store that value to compare against the new value. And you know what? I'm going to actually store the results of that function call, because if I store the results of the function call and the same count value is put in, I don't have to do any of that. I can just say, go get it out of memoization. And then I can actually replace this p with that b zero. Make sense? Pretty simple, right? If I did this algorithmically over and over and over and over and over and over and over and over and over and over and over, what do I get? Well, I get a sequence of if statements placing values into that memoized array where I'm always checking on the dependencies. In this case, button has a dependency of increment, which is a function being passed. I can go to app, still have my use state. I store a new memoized array, which is stored where? In the app node, in the fiber tree that is associated with that function call. And I go through them.

Here's my slow function. Now it has two dependencies, so I'm just going to check, put them in memoization array, see if they've changed. Oh, this one was just the increment function, which has no parameters. No, I only need to ever create it once. So this is my little exception. I'm going to say, well, if it's empty, that spot in the memoization array, then create the function, otherwise just pull it out. Because as long as I do it once, once it's not empty anymore, I know I have the right function. Fine. And I'll call that increment. And we'll do the same. All these little pieces of JSX. This one has num1, num2, and sum, so we check all of those.

And we check, and we check, and we check, and we check, and we check, and we check, and we check, and we output it, and we save. And we refresh. Let's refresh. It's still going to be slow on the initial load. We still are calling that. But watch what happens when I click count. Yay! Super fast! And nothing else is rendering. And when I click the slow one, it's still slow. But counter doesn't re-render. So what just happened? I just memorized everything. But I didn't do it too deeply, did I? I just did it algorithmically. And the result is code that we can understand.

In fact, I dropped this into the React compiler playground, and here's the code that came out. Look familiar? Hmm. Could you write code like this? Maybe you don't want to. You probably could if you really had to, right? But that's the great thing about a tool. It's a tool that goes through and does that work for us, so we can focus on making great applications, on making great software. But the whole idea is that we don't have to think about it.

Why don't we have to think about it? Well, because we have a tool that does it for us. And you don't need to understand the intricacies of how a compiler works in order to use the React compiler. But the most powerful tool a developer can have in their tool belt is an accurate mental model. You will always benefit from knowing how things work. And so, when we look at the compiler, it's not a magic black box that makes your app faster. The compiler is a tool analyzing the text of your code, adding memorization, adding checks on dependencies on function calls, including the JSX, what it's transpiled into, and that's it.

It's code that you could write if you had the inclination and the time. If you were a React compiler. And that's it. I'm Tony Alisea. You can find me on understandingreact.com for full deep dives into React's source code for you and your team. Now's a great time to join me there.

And I hope you enjoy the last talk of the conference. Thanks, everybody, for the pleasure.

Here's a quick question, super off-base. Your first computer. TRS-80 Color Computer 2 Tandy. Okay. Nobody here knows what that is. Yeah, good. All right, all right. All right. There we go. And the other thing I want to say, Ron Harper. Oh, that's it. Yeah, there you go. We're just having a conversation. We had a whole conversation about Cleveland sports. Let's not get into it. All right, not too much time.

Let's get into the first one they're going to like, which was in your code, only the mostly seen value was memorized. Does, oh, it just moved. Does, it just moved again. Hold on. Where are you? Does a React compiler work the same way? Only one value? Trying to understand. In your code, only the mostly seen value was memorized. Does the React compiler work the same way? Only one value. I'm not sure I understand the question entirely. What I will say is the compiler is going through and memoizing the results of function calls, right? And it's always going to be dependent on however many parameters, arguments are passed to that function, as long as the function is pure. Okay. And again, I'm just going to say it, you know, if we read the question, it's not clear enough, what not, there will be a sort of like some opportunities to have just a straight one. Yeah, sorry about that.

If they want to clarify. Oh, yeah, exactly. I want to apologize. I'm not reading it correctly. Roger, thank you for the shout out. But he just wants to say this talk was awesome. So merci, Roger. Not that I should take the credit. This is what we came for.

Are there any memory concerns with memoizing everything? That's a great question. Potentially, right? I think for most common React applications, it won't be a problem. But it is something to be aware of. So if you're going to use the compiler, which is a great tool, it clearly is going to save a lot of work. If you're dumping a large amount of information in the results of your function calls, then you have to be aware that that's going to be sitting, if you're doing client side updates with React, that's going to be sitting in the user's client in their browser. And that's something to at least look at, right, in the browser tools to be aware of. Thank you for that question again. Where did you go? There you go.

How does the React compiler detect when a function's closure values would have needed to change, even if its parameters list is otherwise empty? You know, that's a good question. I know the compiler team, what we showed today is not everything the compiler does. It's not the extent of its abilities. So it is statically analyzing your code and it's using a variety of techniques to do that. So I would say that the compiler clearly has been heavily tested as used in production already. So I think it's just more about the compiler's code doing static analysis and making those determinations by generating abstract syntax trees, by generating everything it needs to generate in order to make those determinations. If somebody is concerned about something working or not working, I say the best thing to do is to try it. Even just drop it in the playground and see what the output is and then go from there. Awesome. I do like this question from anonymous. I believe they're probably quoting, but React docs only memorize expensive computation. Why would React move away from this and are there any memory concerns as we sort of just… Yeah.

Why would React move away from this and are there any memory concerns as we sort of just… Yeah. Well, for one thing with the compiler, you can't opt out. So you can put a note in a particular function to say, please don't optimize this function. So that's a concern. There is opt out abilities. And I think on the other hand, the size of the results for most things, like a piece of JSX or something, is pretty negligible. So I think the original within the React docs about only worry about it for large things is because React is not trying to encourage us to use memo everywhere manually. So you're saying, well, don't worry about memoizing everything. That's unnecessary work. But with the compiler's case, it doesn't really matter because we're not doing that manual work. All right.

What's the most interesting part of React internals? Oh, I think the Fibre Tree is fascinating. How hooks work and really how the reconciliation process comes off of that. But just the Fibre Tree in general is interesting. What we used to call the virtual DOM. So much of what React is and does is now centered around that tree. Scheduling work, pausing work, helping things to be optimized and fast. So I think diving into how the Fibre Tree works is a great thing for a React dev. It's not 100% required, but it's really fascinating and useful. Awesome.

How does the compiler interact with effect dependency arrays? Ooh, that's a good question. I don't think I know the answer to that. I would assume that it probably ignores that. Like the use effect dependency array, because it's already there. It's already kind of only going to run when the dependencies change. But I'm not 100% sure. Aight. And again, if between now and whenever we go to the Q&A, if you want to ask that question again, or you want to clarify, please, the opportunities will be there. Where's that one question? Do you know how all this memorization code affects bundle size? That's an interesting question. Obviously, we are adding some if statements.

But if you actually look at generated code, what JSX transpiles into is probably bigger and more complicated than what the compiler is generating. So I don't think it has as big an impact as somebody might think.

Do I understand that a compiler I am caching the values of functions that children might call and comparing new values against old ones to then update cache? OK, I'm not sure if that's an actual question. Maybe I'm not reading right. Yes, I think I understand what they're saying. Yes, you are. Every time your function is called, rerendered, re-executed, it's comparing to what's already in the cache. If it matches, it's not going to bother executing the function. If it doesn't match, it will execute the function.

In your code, only the mostly seen value was memoized. Does the React compiler work the same way, only one value? That's the top question. In the code, only mostly seen value was memoized. Yes, I think that's the question we asked before. Did I? I feel like I might have to leave that. OK. All right. That's OK. I'm going to try to figure that out afterward. I'm sorry.

So does it work with object and arrays params? Yes, actually, because objects are— you can argue about reference equality in JavaScript, but there is a degree of reference equality in JavaScript.

I'm going to try to figure that out afterward. I'm sorry. Cool. Sorry. OK, I just got logged out. What's going on here? Apologies, give me a second. No worries. Oh, but it's up here. Oh, sorry.

So does it work with object and arrays params? Yes, actually, because objects are— you can argue about reference equality in JavaScript, but there is a degree of reference equality in JavaScript. So an arrays are a special type of object. So you're going to be able to compare those two.

All right. More questions keep coming in. Awesome. In memory, if memory is a concern, could you store a hash of the function argument in the cache instead? That's an interesting question. I feel like that is a possible optimization for sure. Just not sure it's necessary. I think that if you're memoizing what's coming in as arguments, those are probably not going to be massive values. I guess that's another thing to think about. Not only if your function is returning extremely large arrays or objects, but also if you're passing extremely large objects to the function. That's also something to keep an eye on memory-wise. But again, I think that is— if you're passing in incredibly large objects into a function, that may be a smell that something else is wrong with the architecture.

Absolutely. And I believe this will be our last question. Do you have any apprehensions about the compiler? It enables a lot of new features, but are there any risks in breaking from code that doesn't use the compiler? I don't think so. You can look at the code that's generated. That's what I think is the whole idea of not thinking of it as a magic black box. Use it. Look at the code that's generated.

You can understand the code that's generated, and then make a determination. Think of it like some other developer trying to optimize your code and see what it looks like. If you're going to have a lot of code that's being run and being optimized, sure, you may have a concern like, what's going to happen? But again, you could also take it piece by piece. You could say, I know that this particular UI has some issues. I'm going to opt everything else out, and I'm just going to use the compiler there, see what happens, and go from there.

Awesome. Mr. Alisaiah, thank you very much for your time and your presentation. Thank you. Give it up for Tony, please. Appreciate it.

♪♪♪