If You Were a React Compiler

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

If you had the same goals as React Compiler, what kind of React component would you write? In this talk Tony and the audience imagine they are React Compiler, rewriting a React component in the exact same way the compiler does. Along the way, we'll gain a deeper insight into React internals, to fully grasp how the compiler works, why it works that way, and how to decide if you should use it.

This talk has been presented at React Summit US 2024, check out the latest edition of this React Conference.

FAQ

The speaker is Tony Alisea, the director of education for the SMYTH group, who has been a developer for about 25 years.

The main topic of the talk is understanding how the new React compiler works by building an accurate mental model of its functionality.

The goal of a React compiler is to minimize re-renders and skip expensive calculations to improve performance.

A source-to-source compiler, or transpiler, takes code as input and outputs equivalent code with additional optimizations, which is what the React compiler does.

The React compiler optimizes code by adding memoization, checking dependencies on function calls, including JSX, and avoiding unnecessary re-renders.

The Fibre Tree, previously known as the virtual DOM, is a fundamental part of React that helps with scheduling work, pausing work, and optimizing performance.

Yes, you can opt out of the React compiler's optimizations by marking specific functions not to be optimized.

While there could be potential memory concerns with memoizing everything, it is generally not a problem for most React applications. However, developers should monitor memory usage, especially with large data sets.

Tony Alisea considers an accurate mental model as the most powerful tool in a developer's tool belt.

You can find Tony Alisea's deep dives into React's source code on understandingreact.com.

Tony Alicea
Tony Alicea
26 min
19 Nov, 2024

Comments

Sign in or register to post your comment.
  • Christos kuznos
    Christos kuznos
    None
    Thank you @Tony Alicea for the explanations, it true that I didn't check the QA.
  • Tony Alicea
    Tony Alicea
    The Smyth Group
    @Christos kuznos As I mentioned in the Q&A, you should keep an eye on browser memory if you are passing around extremely large objects in your code. Other than that, the downside is that it's another layer of abstraction -- the code you write isn't what's given to the browser, so there's debugging difficulties potentially there. Overall, though, I don't think the upsides outweigh any potential downsides.
  • Christos kuznos
    Christos kuznos
    None
    any downsides?
Video Summary and Transcription
In this talk, the speaker aims to build an accurate understanding of how the new React compiler works, focusing on minimizing re-renders and improving performance. They discuss the concept of memoization and how it can be used to optimize React applications by storing the results of function calls. The React compiler automates this process by analyzing code, checking dependencies, and transpiling JSX. The speaker emphasizes the importance of being aware of memory concerns when using memoization and explains how the React compiler detects changes in function closure values. They also mention the Fibre Tree, which drives the reconciliation process and helps optimize performance in React. Additionally, the speaker touches on JSX transpilation, compiler caching, and the generation of code. They encourage developers to understand the code generated by the compiler to optimize specific sections as needed.
Available in Español: If You Were a React Compiler

1. Introduction to React Compiler

Short description:

In this talk, the goal is to build an accurate mental model of how the new React compiler works. We're going to pretend that we're the React compiler and try to do what it does. Our focus is on minimizing re-renders and skipping unnecessary calculations to improve performance. The React compiler is essentially a source-to-source compiler, taking code as input and outputting equivalent code with extra features. As a compiler, we analyze the code and may convert it into an abstract syntax tree before outputting new code.

[♪ 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.

2. Proceeding Algorithmically to Minimize Rerenders

Short description:

We're going to proceed algorithmically to avoid useMemo, memo, and useCallback. Let's start by looking at a contrived example of a simple counter with unnecessary rerenders. By proceeding algorithmically, we can find a solution without manually using memos and callbacks.

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.

3. Memoization with Custom Hook

Short description:

I'm going to be prepared to put things into memoization. I'll define the concept of empty and create a custom hook, C for cache, to memoize an array of values. Instead of using use memos everywhere, I'll have an array of values at the top. The memoized values are stored in a JavaScript object in the browser's memory and accessed through the fiber tree.

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.

4. Memoizing Functions and Dependencies

Short description:

I want to put functions or the return values from functions into memory. Functions are pure in React, meaning they always return the same output for the same input. This allows me to memoize or store the value of a function and avoid running it again. In JSX, which is converted into function calls, other functions are being called internally. Memoizing these functions and their dependencies, such as children, can optimize performance.

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.

5. Optimizing Memoization with JSX and Dependencies

Short description:

If I'm starting to think about this programmatically, I'm going to check if the value is equal to count and if it's already stored in the memoization array. If not, I will call the function again and store the result. By doing this repeatedly, I create a sequence of if statements that place values into the memoized array. Each component has its own memoization array in the fiber tree. The slow function has two dependencies, which are checked and stored in the memoization array. If the array is empty, the function is created, otherwise it is retrieved. The same process is applied to all JSX components with their respective dependencies.

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.

6. Understanding the React Compiler

Short description:

I just memorized everything. The result is code that we can understand. The React compiler is a tool that does the work for us, allowing us to focus on making great applications and software. It's not a magic black box, but a tool that analyzes the code, adds memorization, checks dependencies, and transpiles JSX. Understanding how the compiler works is valuable, but you don't need to know all its intricacies. Join me at understandingreact.com for deep dives into React's source code.

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.

QnA

React Compiler and Memoization

Short description:

The React compiler memoizes the results of function calls, depending on the parameters passed. It works similarly to how the mostly seen value is memorized in your code. If the question is unclear, there may be opportunities for a more straightforward explanation.

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.

Memory Concerns and Function Closure Detection

Short description:

It is important to be aware of potential memory concerns when memoizing everything in React applications. While the React compiler can save a lot of work by memoizing function calls, dumping a large amount of information in the results of these calls can impact the user's browser performance. The React compiler detects changes in a function's closure values by statically analyzing code using various techniques, such as generating abstract syntax trees. It has been extensively tested in production and can be experimented with in the playground to understand its output. There is a question about why React moved away from only memorizing expensive computation, which can be explored further.

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.

React Compiler: Memory Concerns and Fibre Tree

Short description:

React moved away from manual memoization because the compiler optimizes function calls automatically. The size of results in most cases is negligible. The Fibre Tree is the most interesting part of React internals, as it drives the reconciliation process and helps optimize performance. The compiler's interaction with effect dependency arrays is not clear, but it may ignore them. The impact of memorization code on bundle size is an interesting question.

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.

JSX Transpilation and Compiler Caching

Short description:

JSX transpiled code is usually bigger and more complicated than the compiler-generated code. The compiler caches function values and compares them to update the cache. In the React compiler, only the mostly seen value is memoized. It works with object and array parameters due to reference equality in JavaScript.

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.

Memory Optimization and Code Generation

Short description:

I'm going to try to figure that out afterward. So does it work with object and arrays params? Yes, because objects and arrays have reference equality in JavaScript. In memory, if memory is a concern, you could store a hash of the function argument in the cache instead. However, it may not be necessary as memoized arguments are usually not massive values. If you're passing in incredibly large objects into a function, that may be a smell that something else is wrong with the architecture. There are no risks in breaking from code that doesn't use the compiler. You can look at the code that's generated.

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.

Understanding Generated Code and Optimization

Short description:

You can understand the code that's generated and make a determination. Take it piece by piece, optimizing specific sections. Thank you, Mr. Alisaiah, for your time and presentation.

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.

♪♪♪

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

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.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
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.
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.
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.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
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 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
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.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
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.