How to React Compiler

Hello, everyone, and welcome to my talk about the React compiler. My name is Anton Nevsha, and let me introduce myself real quick first before we dive into the React compiler world. I have 11 years of commercial experience as a front-end engineer, and events and conferences like React Summit is really what inspires me and makes my life better. So, yeah, really glad to be with you here today.

For my career, I develop online banking apps, and some of those are actually in production, working on the React compiler. So, I just really wanted to share with you my experience with the adoption of this technology, of this tool. And let me start off by stating that the React compiler is not the same as React 19, right? So, for some of us who are still getting familiar themselves with the technology, it's worth noting that just installing React 19 won't give you the benefit of those automatic memorizations and other features that React compiler has to offer.

So we would need to install yet another package called Babel plug-in React compiler, which is a separate package from the NPM. And this is pretty straightforward to configure it and to install it, because all we have to do is to specify the name of the plugin in our V configuration file, and we're good to go. Another thing is that we can also specify the target version of React if we are working with the older versions of React, let's say 17 or 18. And configure it this way would give us this result. This is the output file, and the input component, and the output component that is processed with the React compiler. What it basically does is it detects the props or variables that our component is dependent on, and based on their behavior, if they're changed or not, it would recompute the output of the component or just return the pre-computed output of the component.

And that is basically it. But the interesting thing about this is that, if we configure our React compiler like this, placing this little configuration object in the plugin configuration file, we would actually end up with having this much settings, and this much options and configurations. Those are the default options that React compiler has to offer, and we would actually be careful with those, because some of them are straightforward, but others, like this environment key, it basically contains an object with 30 or 30-ish other configurations and options.

And if you want to see what it's doing and see what they are, the best place to refer to is actually React compiler playground website. And here on the right side, there is this environment config section, which is expandable, and no one actually talks about it for some reason. Never. But this is the best place to figure out what configuration is best for your project, basically. And here on the left side, there is the sample component that I'm using.

This is the type of components that we've all seen. There is this list function that accepts a people array, and the problem is that we have to iterate over each element within this array to create some sort of JSX markup. And it's no big deal, right? But the fact is that whenever any of the items within the array change, or if we, let's say, add some more items to the array, we would still have to recompute all the items within this array once again. And normally, before React compiler, we would end up extracting this JSX part into a separate component and also wrapping it in react.memo, just to make sure we wouldn't recompute those items again.

And the brilliant part about React compiler is that it actually has the same feature extracting the JSX part from the array map callbacks. It can do this automatically for us, and the problem is that the feature that is responsible for doing it is enabled by default. But in this example, we still don't get the automatic memorization. We still don't see how this JSX is being extracted because this JSX part is still a part of the larger function. It's not a separate function. Well, why is that? Because the enable function outlining over here is set to true, and this is the exact option that is responsible for extracting it.

Well, the thing is that this enable function outlining feature has its own limits. The particular issue here is that, in our components, we have this style variable defined, and the problem is that it is declared outside of the array map callback scope. You see it's declared outside, and this is something that enable function outlining cannot tolerate and cannot work with. But luckily, we still have some workarounds with the environment, and we can also enable another feature called enable JSX outlining, which is currently set to false by default, but we can easily enable it. It's a little bit tricky in the Playground website because this right part is not editable. You cannot write anything here. You cannot type anything or change anything here.

So, how do we enable all the flags that we want to? Well, this is actually pretty simple. We would have just to add a comment somewhere above our function and add an annotation corresponding to the flag that we want to enable. This annotation enable JSX outlining, which we placed here, would enable the JSX outlining flag over here, which, in turn, would change the output of the React compiler. And now you can see that we have a different output, basically. We have this const t0 equals underscore temp, and this underscore temp function is basically a separate function, absolutely independent from what we had before. This function is declared here in the below the previous component. And we see that this function actually looks like a React component that is being memoized in the same way that React.Memo does.

And we see that this function actually looks like a React component that is being memoized in the same way that React.Memo does. So, this is great news, and this is something we can work with. Great.

One major thing about React compiler is that while I worked with React compiler, it was still in beta. And when the project is in beta, it's not a surprise that something can change. Something can be developed further. Something can be not quite as good yet. In order for us to not break anything and to make sure the integrity of our app did not suffer, we should at least know what can be broken.

These are the things that can be broken with or without React compiler. These are the error messages that you get when working with the React compiler, and those three are pretty straightforward. When you have invalid JS or invalid React, it's no surprise that React compiler won't deal with it. It's not React compiler-specific. This is something no Babel plugin would tolerate and would break. If you have a valid configuration, it can also result in an invalid output. But there are some specifics for React compiler, and some of them are quite funny.

One of those is to-do or invariant. Those are basically some internal React compiler errors that might tell you that something is not finished yet with the development of the React compiler itself. As an example, I can give you this component. Whenever you have the variable called FBT declared somewhere in your components, you see that you may not even want to use that. But just the fact that you have this variable and it has the name FBT makes React compiler throw an error at you, saying that the support of the local variables with the name FBT is not supported yet.

But this is just a fun thing to keep in mind, and I'm sure it's going to be fixed soon. But there is one more important error that you might come across, which is that it cannot preserve memorization. Now, this error occurs when React compiler cannot guarantee us that the memorization level that we had is the same after the React compiler does its job. So, it's not sure if the level of memorization stays the same. This is a big deal. This is great news that we have these errors stating that some of the components aren't that well memorized as they used to be.

But the fact is that this error message is hidden by default. If you want to see those error messages, you may want to specify the panic threshold setting in your plugin configuration, basically so that you'll be able to see which component is not supported by React compiler and which is doing okay. So, by default, what React compiler does is just skip the component that it cannot memorize properly. If you want to see some more info about that, you may want to enable this feature. And one more useful thing is that there's this environment flag called validate preserve existing memorization guarantees.

Now, what it does is, actually, it is responsible for throwing that cannot preserve memorization error. So, if you enable this validate preserve existing memorization guarantees flag, you will see those errors more often, and you would more often see if some of the components aren't being memorized good enough. This flag is recommended by the React compiler team to be enabled when you're migrating your codebase to the React compiler, but it's disabled by default. Make sure to enable it to see what's going on with your codebase. What this option does is, basically, it gives you errors when somewhere in your codebase there are hook dependencies that are used wrong, or some hook mutations going on, or some other rules of React being broken.

There are more validation tools and more validation options you can specify if you want, but those are also straightforward and speak for themselves. Like validate no set state in render, this is clear what it means. So, you can specify those if you really need them. And there are some other lessons that I've learned with React compiler when working with it, and one of my favorite things is the way React compiler treats hooks.

Let's imagine we have this example component that uses this useAccessibility hook. It doesn't actually matter what exactly it does, but all that matters is that it's a useMemo. If we know useMemo, it's pretty straightforward. It just remembers dependency variables and fires the function if the dependency change. So, I have this console log over here, but we are pretty certain that this console log wouldn't be executed if product or flag dependencies aren't changed.

But, let's see what's going on with this component and with this hook after we compile those with React compiler. Now, as for the component itself, this is pretty simple, actually. We still have this useAccessibility hook call, and if it's a hook call, we cannot place it within the if statement or within a conditional. So, it's basically where it belongs. It's the top level of the function, and it's been executed each time the component is being rendered. But, as for the hook itself, well, now we see that this console log is being executed far more often because it's been executed even before we check the flag or product dependency. So, this is some sort of change in behavior and changing the way we memorize things, and there are several ways to deal with that.

The first thing that can help us is just changing the way we work with hooks and just renaming them and getting rid of the hook itself. Let's say we have the useAccessibility hook, and we should convert it into a getAccessibility function that won't work as a hook, and won't comply with the naming conventions of the hook, and won't be compiled by React compiler. Imagine what we had before. We had this useAccessibility hook executed every time. But, if we had the getAccessibility function, it would be pretty normal to just place it within the if statement, thus retaining the same level of memorization that we had before.

This is great news, and another example of how we can do this is we can just use those declarations like useNoMemo or useNoForget. Those declarations would tell React compiler to skip the component or the hook, and it will remain the same as it used to be. This is also the way to retain the same level of memorization. Another workaround is just not to keep this logic in the view layer. You can just place it somewhere in your state manager, or somewhere above the React layer, somewhere like this.

Let's also talk about hook return values. They should be mutable, since it's a React rule, and, while working with them, imagine this example where we have this status key variable, which is a result of useMemo call. Whenever we pass it into some function, even though this function might not even mutate this exactly, like this internationalization translate function, which does not mutate the key, it just accepts it. But still, React compiler wouldn't be happy with that. It would throw us an error, because we basically violate the rule of React to mutate this hook return value. What we can do with that is just reorder some project structure a little bit, or we can disable the environment flag that I told you before, validate preserve existing memorization guarantees.

If we set it to false, it won't react to those situations, even though it's a violation of React rule, and it should react to that. Or, you can just get rid of useMemo, because this is a classic example of us just removing the useMemo completely, and having the same output as before, because this is what we would get. This is just the same as with using useMemo.

So, we have this getStatusKey function that's being executed only if the entity variable is changed. This is exactly what we need. There is more to this component example. I just wanted to illustrate you a little bit a little tricky situation. So, imagine you have this component. This is the same component that we used before, the one with the status key. Let us imagine that one of your co-workers opens a PR, trying to add some more data in this component.

Let's say they just add a name property, and they change the JSX output a little bit. This is no big deal, and we would accept this PR, most certainly, even though we just won't talk about why the name property and entity are separate properties, but let's leave it as it is, and accept this PR. But, if we would use React Compiler, we would want to give this PR a second thought, basically, because this is what our component looked like before the PR.