React Compiler - Understanding Idiomatic React (React Forget)

Spanish audio is available in the player settings
Rate this content
Bookmark

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. 

33 min
20 Oct, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.

Available in Español

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.

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

JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Top Content
Vite is a new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
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 Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
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.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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