React Compiler - Understanding Idiomatic React (React Forget)

So, yeah, I'm Joe. Is this too loud? It feels loud. All right, good. So, I'm Joe. I'm an engineer on the React team at Meta and in this talk we would like to share our vision for client-side React development, specifically I'm talking about React Forget. Forget is a compiler that we've built at Meta that automatically memorizes your components and hooks. So if you were hoping for us to be open sourcing Forget today, I am sorry to disappoint you. But we've made a lot of progress and we're excited to share more about that with you today.

So, I'm going to be talking about what our vision is, what Forget is, and how it fits into that vision. And then Mofe is going to come up and talk about our progress shipping Forget at Meta.

So to understand our vision for React, it helps to look at some code. Here I'm showing a simplified version of an internal component from Meta. This component takes a heading, a list of videos, and a filter. And then it renders the heading and list of videos that match that filter. You can imagine the real component is more complicated. You know, the filters actually state, et cetera. It's a kind of simplified version. So personally, I think there's a lot to like about this code. It's a small, clear, concise component. It uses plain JavaScript values, arrays. We use standard JavaScript syntax, if-else for conditionals, a for loop for iteration. We don't need to learn something new, this is just the JavaScript that we already know. Use the platform.

So in a lot of ways, this is React at its best. We use this UI as a simple function of data. There's really only one potential problem with this code. If we were to ship this as-is, we might see the parts of our app rerender unnecessarily, and that can affect performance, slowing things down. So let's see an example of how that can happen. Imagine that our component rerenders, but only the heading has actually changed. When the component renders, it passes that new heading down to the heading component, which updates as we'd expect.

But that's not all that happens by default. When our component rerenders, the entire component reruns. This entire function reruns. That means we create a new filtered videos list, and then we pass that to video list, which then also rerenders all the way down the tree. And this will happen all the way down the tree. Even though nothing meaningfully changed about the videos.

To address this, we can use two React APIs, usememo and react.memo. So here, I've applied usememo to the logic for filtering the videos. The array at the bottom here tells React to only recompute filtered videos if the videos or filter values have actually changed. So now if only the heading changes, we don't recompute the list of filtered videos. Great. But that's not quite enough. Because even though we're passing the same filtered videos down to the video list component, by default, React will still re-render a component, even if its props haven't changed. To opt out of that, we wrap the component with react.memo. So now we get the expected performance with these two changes. Now when heading changes, we won't have to update the video list component. Great.

But if you judiciously apply React use memo, use call back, which is kind of the call back version of use memo, and then react.memo, if you use them consistently throughout your codebase, you can achieve really good performance with React. And a lot of other presenters have talked about that earlier. We found that generally when applications do have a performance problem, it's because of this kind of missing memoization and it can be fixed by just adding this back.

Memoization has made our original code a lot less concise and clear. We're no longer simply describing what the UI should be showing. We're having to tell React how to process our code. That's kind of losing some of the original idea of React, right? Declarative rendering. But now we're having to go into the how. And then our code reviews become about whether we've memoized correctly, whether we've memoized too little, too much. We get blog posts saying you shouldn't memoize at all, you don't need memoization. And the thing is both of them are kind of right, because it all depends on the context. This code, the original code here might be fine in a lot of apps. But for other apps they might run into a performance problem.

But really, with this memoization, our code gets cluttered up with extra logic. We're not just focusing on the core product experience, we're focusing on, again, how to achieve it. It makes our code harder to read and harder to change. So, in a sense, useMemo is a compromise.

We sacrifice some of the clean, concise, original logic in exchange for better performance. But why do we need to make this compromise at all? Well, let's go back to the code. The reason we started down this whole path was that we needed to use useMemo to tell React that the video list doesn't depend upon heading. But we're all developers, we know JavaScript, right? We've already told React that video list doesn't depend upon the heading. In fact, we've used a very well-specified format of instructions that computers already understand to tell React that information. It's called JavaScript. You already know it, right? So why do we have to tell React again? Why do we have to also add in our use memo to tell React, oh, this doesn't depend upon these values? What if React could figure that out automatically? And better yet, what if React could figure this out at build time when you compile your app? And didn't you?

...design decisions, but might need to make further adjustments and optimizations, depending on data. Our next step is to scale up until forget is used everywhere at meta, refining on small details. Finally, when we have stress tested and iterated enough, we release. While we still have some work ahead of us, we strongly believe that forget will help React achieve its vision, an ergonomic developer experience, paired with great performance. Thank you.

We're going to jump right into the audience questions. So hope you're ready. First question with the most upvotes is does this completely remove the need for use memo, memo and use callback? Yeah, so long term, the idea is that we would like to remove those APIs completely. Obviously, long road to get there. But that's the goal, yeah. Great. That's nice. It's one, in my experience, one of the harder concepts to grasp. But yeah, something that you need to grasp if you're building a big application. So super nice. How does React... Why is it called React Forget and not React Remember? The previous question was really good. I was excited about that. I wanted to answer that. Okay, well I know what it was.

We're gonna get to that. Oh, okay, okay. All right. Why is it called React Forget? So we have a policy to name all things with F-words that are puns, and so remember is not, yeah, it's not an F-word. All right, fair enough. We like F-words. Dan? We're New Yorkers. No swearing onstage. I didn't say it. Go ahead.

Next question. The best question. From David. How does React Forget know when to not unnecessarily apply memoizations, such as when memoization is more expensive than no memoization at all? So we do two things here. The first is escape analysis. We look at the values actually returned from the function, like from JSX, or values being passed to hooks as inputs. So we only memoize values that eventually make it out of the function. The second is that we do some type inference to not memoize primitives. So things like array.length, for example, we can infer is a primitive. And since that's not going to cause unnecessary re-rendering in React children, we're currently choosing to not memoize those. Cool, thanks.

Next question is, you mentioned Forget is for client-side React. How does this project fit into the React server component's paradigm shift? Will Forget perhaps play a bigger role in React Native? Yeah, that's a great question. So we don't see client-side React going away. RSEs expand React. They don't diminish the need for the client-side React to handle the interactive parts of your app. And so for the parts of your app that remain interactive, Forget helps to make them faster by default and improve the developer experience there. But I think the other bit is that Forget is a compiler for React. And so the first thing we're doing with that compiler is optimizing the client-side developer experience. But we have other ideas about how to build on the analysis that Forget is doing.

For example, maybe doing optimized server builds. If you're doing SSR, Forget could figure out that use state isn't going to run in an SSR environment and strip that out. And then you could do some dead code elimination from there and have a more optimized server build. So you have more ideas for what to do given this compiler platform in the future.

Great, thanks. Next is a question from Dennis Kroekneet. Why not make it open-source so we can improve it as a community? Yeah, we will do that when it's ready to open-source. I think Mofay, you covered that, right? And I think at the last slide really like the kind of the stages we go through. I think we have kind of unique access to like data scientists. Yeah and like I don't know if you want to... Yeah, and I think there's no better stress test than the scale of Facebook, right? So everyone that wants to improve, they're not going to have, or most of them are not going to have the scale as you guys can have for stress tests. Yeah, I feel like you want to like share more about kind of like, I don't know if there's any more you want to share about, like what we've gone through internally just to look at. You have some pretty crazy code at Facebook. We have like thousands of engineers writing code over a decade at this point, almost a decade. We've seen really interesting use cases and we hope at least that all of our experience rolling out for Git at Meta will only make it better for the open source community. Yeah. Yeah. And is that something... When you're developing this stuff, is it something like, it's always built for Meta or is it something that you really keep in mind then, like this also for the rest of the community? Because Meta is paying the bills, of course, so I would completely understand.

Yeah. We spend a lot of time thinking about our open source release strategy. So, over the past, I don't know, a couple of months, we've... Whoa. That's a lot of people. Oh. We are trying out for Git on open source apps as well. Use for Git and apps like using other frameworks like Remix, Next.js just to make sure it fits in the pipeline. Yeah. Yeah. That's great to hear.

Thanks. Next question from Metin Parzhinski. Is this something that we'll need to install, or will it just be in version X of React? It's part of the build pipeline, so it is something you'll have to install. There's a small dependency, and it depends on one additional runtime API in React. So it will require at some point that will go out in a stable version of React. And once you've upgraded to that version of React, you'll be able to add the Babel plugin.

Yeah. Okay. Awesome. Well, the question that we knew was coming, when is the React for Git due to be released? I think Mofe described it in her section of the talk. So definitely refer back to the talk, and we kind of walk through the steps that we go through, initial prototype, iteration, refining it on more and more products that meta, and then releasing. There's, as you mentioned in the talk, we hold ourselves to a very high bar, right? But there's not just the quality of what we're releasing, but things like documentation, being available to answer support questions, being able to actually review pull requests that fix bugs. So we want to, when it is open source, we want to have it really be a good open source project. But that takes work from us that would take away from actually finishing Forget and making it what it needs to be. So we think that the right thing to do right now is really make Forget as awesome as it can be so that it's ready to go out into open source.

All right. So everyone can forget about React, forget until it's released. That's the message, yes. But thanks a lot for this intro. We lost track of time. We were supposed to finish four minutes ago. So thanks a lot for being here. Yeah, thank you.