React Compiler - Understanding Idiomatic React (React Forget)

React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 

Spanish audio is available in the player settings
Rate this content
Bookmark
Video Summary and Transcription
The video explores the concept of React Forget, a compiler developed by Meta to enhance client-side React development. React Forget aims to streamline performance by automatically handling memoization, reducing the need for developers to manually use useMemo or react.memo. The talk highlights how React Forget uses escape analysis and type inference to identify dependencies, thus improving application efficiency by avoiding unnecessary rerenders. The discussion touches on React Forget release date, noting that while no specific date is set, the goal is to release it as an open-source project once it meets Meta's quality standards. The video also delves into idiomatic React, emphasizing the potential of React Forget to optimize server builds and enable dead code elimination. With React Forget, developers can expect an ergonomic experience, as it aligns with the vision of making interactive parts of apps faster without compromising on code clarity.

FAQ

Yes, the long-term goal of React Forget is to eliminate the need for useMemo, react.memo, and useCallback by automatically handling memoization.

React Forget uses escape analysis and type inference to determine when to memoize components and hooks. It only memoizes values that make it out of the function and avoids memoizing primitives to prevent unnecessary re-renders.

React Forget is not open-sourced yet because Meta is still refining and testing it internally. They want to ensure it meets high standards for quality, documentation, and support before releasing it to the open-source community.

React Forget is a compiler developed by Meta that automatically memoizes your React components and hooks to improve performance by reducing unnecessary re-renders.

No, React Forget is not currently open-sourced. However, Meta plans to open-source it once it has been sufficiently refined and tested internally.

React Forget complements React server components by optimizing the client-side developer experience, making interactive parts of apps faster and improving overall performance.

Yes, React Forget will be part of the build pipeline and will require a small dependency and an additional runtime API in React. It will be available in a future stable version of React.

There is no specific release date for React Forget. Meta is currently refining and testing it internally and plans to release it as an open-source project once it meets their high standards for quality and documentation.

The name 'React Forget' is part of Meta's policy to name projects with F-words that are puns. 'Remember' does not fit this naming convention.

React Forget improves performance by automatically determining when to memoize components and hooks, reducing unnecessary re-renders without the need for developers to manually add useMemo or react.memo.

1. Introduction to React Forget and Our Vision#

Short description:

I'm Joe, an engineer on the React team at Meta. I'll be talking about our vision for client-side React development and React Forget, a compiler we've built at Meta. Mofe will discuss our progress shipping Forget at Meta. We use plain JavaScript values and syntax in our code, which allows us to use the platform efficiently. However, there's a potential problem with unnecessary rerenders in our app, affecting performance.

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.

2. Optimizing Performance with Memoization#

Short description:

By default, when a component rerenders, the entire component reruns, creating a new filtered videos list. To address this, we can use usememo and react.memo to optimize performance. By applying usememo and react.memo consistently, we can achieve good performance with React. However, memoization can make the code less clear and lead to debates about its usage. The need for memoization depends on the context of the application.

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.

QnA

Memoization and the Vision of Forget#

Short description:

With memoization, our code becomes cluttered with extra logic, sacrificing clean and concise original logic for better performance. We question the need to explicitly tell React about dependencies when we have already specified them in JavaScript. Can React automatically figure out dependencies at build time? We believe Forget will help React achieve its vision of an ergonomic developer experience with great performance.

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.

React Forget and Its Role#

Short description:

React Forget is named with an F-word pun, following our naming policy. It knows when to apply memoization by using escape analysis and type inference. Forget is for client-side React and helps make interactive parts of the app faster and improve the developer experience. It is a compiler for React, with potential for further analysis.

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.

Optimizing Server Builds and Open-Source Strategy#

Short description:

Forget could optimize server builds, strip out unnecessary code for SSR, and enable dead code elimination. The team plans to make it open-source when ready. They have unique access to data scientists and the scale of Facebook for stress testing. They have seen interesting use cases and hope their experience will benefit the open-source community. The team spends time on their open-source release strategy and is trying out for Git on open source apps and other frameworks like Remix and Next.js.

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.

Installation and Release of React Forget#

Short description:

The React for Git release date was not provided in this part. The team is focused on making Forget as awesome as it can be before releasing it as an open-source project. They want to ensure it meets a high bar in terms of quality, documentation, support, and bug fixing. The goal is to have Forget ready to go out into open source.

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.

Joe Savona
Joe Savona
Mofei Zhang
Mofei Zhang
33 min
20 Oct, 2023

Comments

Sign in or register to post your comment.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vite: Rethinking Frontend Tooling
JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a next-generation build tool that leverages native ES modules for improved performance. It eliminates the need for bundling and improves hot module replacement. Vite provides an opinionated default configuration while still allowing advanced customization through plugins. It is framework agnostic and can be used for React and other applications. Vite is being adopted by Next.js and Create React App, and integration with Nuxt 3 offers significant speed improvements.
A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Web3 Workshop - Building Your First Dapp
React Advanced 2021React Advanced 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn