Inside Fiber: the in-depth overview you wanted a TLDR for

Rate this content

I want to provide an in-depth overview of the important concepts behind reconciliation. We'll then explore how React uses the algorithm and go through a few magic words we hear a lot, like coroutines, continuations, fibers, generators, algebraic effects and see how they all relate to React.js.

27 min
17 Jun, 2022


Sign in or register to post your comment.

AI Generated Video Summary

This Talk explores the internals of React Fiber and its implications. It covers topics such as fibres and units of work, inspecting elements and parent matching, pattern matching and coroutines, and the influence of coroutines on concurrent React. The Talk also discusses effect handlers in React, handling side effects in components, and the history of effect handlers in React. It concludes by emphasizing the importance of understanding React internals and provides learning resources for further exploration.

1. Introduction to Inside FIBR

Short description:

Hi, everyone. This session is Inside FIBR, the TRDR you wanted for. I'm Mateusz, a senior front-end engineer at Medaglia and a mentor at Tech Labs Berlin. React source code is complex, but we can discuss it further. I wanted to present this because of my friend Bruno's proposal to bring algebraic effects into JavaScript. I'll explain the topics and their connection to React.

Hi, everyone. It's great to be here. Hello, Amsterdam. Hello, everyone who's online. Yeah, I'm Mateusz and this session is Inside FIBR, the TRDR you wanted for. This is me. You can find me everywhere as Ytacombinator and I'm a senior front-end engineer at Medaglia and I also mentor front-end people at Tech Labs Berlin.

By the way, we are hiding. Before we start, I have a few disclaimers. The first one is that, as you probably can imagine, React source code is really complex and some of the thoughts I have here are a bit speculative. And the second thing is that maybe it's going to be not 100% what you call a TRDR, but whenever you find the huge payload of content, you'll see this icon, which means we can discuss that in the afterparty or in the Q&A sessions and etc. So don't worry.

Before I start, I'd like to provide you a bit of context of why I wanted to present this and why I wanted to talk about these stuff. It all started with this friend of mine called Bruno. He was preparing this proposal to bring algebraic effects into JavaScript, so it was just like regular TC39 proposal, and he asked me for some feedback. When I was reading his proposal, I thought I saw a huge amount of topics I had never heard about any of them, and there was this huge cloud in my mind, like algebraic effects, coroutines, continuations, fibres, threads, generators, and etc, and what I wanted to do here was to put those in a way that it makes sense to go through them and also to show how they all pieced together and react.

2. Overview of Fibres and Units of Work

Short description:

Fibres in React are similar to stack frames in regular JavaScript functions. They represent units of work and allow for tracking, scheduling, pausing, and aborting specific types of work. During reconciliation, elements are merged into alpha fibre nodes, which describe the work to be done. Visualizing these units can be done through inspecting elements, providing valuable metadata about components.

So starting with fibres and a bit of an overview. The way I like to see fibres is let's think about a regular JavaScript function. So we have this add functions, it has two parameters, I'll just sum them. If you think of what a stack frame for that would look like, we would get something like this. We have a return, we have the function itself, we have a few parameters and the local variables being the numbers or results.

If we think about a React component, we can get to something similar. So we can think of a fibre in this way where we have our components instead of a function. Our props instead of our parameters and then our component state being our local variables. So to start, we can think of the fibre architecture as this React specific call stack model that basically gives full control over scheduling of what should be done. And, a fibre itself is basically a stack frame for a given React component. Okay, we got to this definition, we got to this parallel with regular stack frames, now we can start seeing fibres as units of work.

So let's think what happens with our components. So once our template goes through the JSX compiler, we end up with a bunch of elements that's what you note. What happens next is during reconciliation, the data from all of these elements is merged into three alpha fibre nodes, then we'll talk a bit more about them. And then, of course, depending on the type of, what is it, for example, it can be a function component, a class component, a suspense component, or whatever, so depending on the type of the thing, React itself needs to perform different types of work. So it's going to tag these. And then, each element is converted into this fibre node that we're talking about, that's going to describe for React what kind of work that needs to be done. So this leads us to this unit of work thing. And because fibres are units of work, it makes that convenient to track, schedule, pause, and abort specific types of work.

Now that we can abstract those in terms of units of work, we can also think about visualizing those units. And for this, I'd like to propose this first experiment that is inspecting elements. So let's take this simple app. I have just a few components with some local state and I have this button. I am incrementing and decrementing this local state and that's about it. If we start logging our fibres in the console, we are going to see this, a bunch of metadata about our components. And we'll see metadata about props, about state, about etc. And I know it was like really tiny but don't bother trying to read that. But I just wanted to see that there's a bunch of information there. And we can use, for example, this kind of information. So here's a piece of code where I'm using only five of these properties to iterate on those fibres.

3. Inspecting Elements and Parent Matching in React

Short description:

Now I can inspect elements and get metadata about components. React has 25 different types of tags that can be used to tag what needs to be done. The more React adds features, the more these tags grow. React elements are just data, allowing us to manipulate them. Another experiment is parent matching in React, where I match a response of an API and render components based on the match.

And what I'm going to get is, now I just copy and paste the code into developer tools and now I have Twitter open with a red summit profile open. And I was iterating and storing those in a regular JavaScript map. And what I have now is that, for example, I can inspect a given element of that. So because those are in a map, I can click that and find those in the map. I get a lot of metadata about components.

For example, I can figure out that Twitter uses a lot of class components. So what I would recommend you to explore those is this part of the reconciler, it's called React internal types. So there you can see literally any all the properties of the fiber and what kind of data they store. And another really interesting part is this word tags. Because you will see that, for example, React has 25 different types of tags that can be used to tag what needs to be done. For example, an error boundary, a suspense component, a profile component, a regular class or function component. And you will see this keeps growing. Last time, a few years ago when I checked it was like five. So the more React adds features, the more you see those growing. Now that we can visualize those, we can also talk about manipulating them.

So I'd like to be a little bit of raise your hand here. Who here has ever heard about homo iconicity? So, this nice word is you'll find like in Wikipedia or some other sites that basically this is a property of programming languages in which the code used to spread the program is written using the data structures of that language. This is really easier to visualize in languages like Clojure, for example, or Lisp. But for now, let's take this, your code is data and your data within the problem is the code. What we just saw that React elements are just data as well. So, we can start thinking of React and home-iconicity. And just like Lisp and those languages that have this property, we can manipulate an element children or their properties in the way we want. And this allows us to do interesting things.

The second experiment is parent matching in React. I have this example of code where basically I have a match component and I have with and otherwise. And basically... And this is typed. But what this code is doing is I'm trying to match a response of an API. And if it's an error, I'm going to render my error component. If it's an image...

4. Pattern Matching and Coroutines in React

Short description:

If it's okay but it's an image, then I'm going to render a component and then if it's a text, I'm going to render a different component. That's pattern matching. Coroutines are generators or producers that can consume values. They can also resolve async values and be used with a stack continuation. In React, fibers provide control paths to the scheduler, determining what runs next.

If it's okay but it's an image, then I'm going to render a component and then if it's a text, I'm going to render a different component. That's pattern matching. And this is built by checking elements internal metadata. By the way, the code for that is on GitHub.

Now, we can move to the next thing. Coroutines. I started reading about coroutines after I saw this tweet by Andrew Klock. He's from... He used to be in React. And basically he said that React suspends would trick people into learning about coroutines. And he was right. And then I started digging definitions out there for that. And I saw many of those.

Being the first one that coroutines is a generator or a producer that can also consume values. So if you think about this, the generators we have in JavaScript, they can also consume that. So by this definition, those would be coroutines. Another definition I found was that those are generators that can resolve async values. Just like we have with async await, for example. And this definition is also really common in JavaScript. Because for example, you can even remember coroutine before promises were really a thing. Basically promise implementations based on generator. And even bubble under the hood, it also does that. And the last one is, like, the one with more buzz words, is that it's a generator that can use with a stack continuation. And I know it sounds complicated. But we can think of this one as we had deep await. If you're familiar with React suspense, you can think that you can pause reconciliation at any depth of your component tree.

So to sum up, we saw fibers, and in fibers, to summarize, we have control paths to scheduler. For example, React scheduler. And this scheduler is going to determine what runs next. It can be, for example, node.

5. Coroutines and Their Influence on Concurrent React

Short description:

Coroutines in React give developers control paths to the caller, providing full control of pausing and resuming. However, coroutines no longer exist in React for visual experiences. Coroutines as an abstraction may have influenced concurrent React. An experiment is proposed to demonstrate the impact of a CPU-bound operation on a component's performance. By using a coroutines-based scheduler, the lag caused by the operation can be eliminated, resulting in a better user experience.

It will be something similar. Whereas in coroutines, basically you have control paths to the caller and handled by your code. So by developer code. So that's the key difference for these two.

Now we can talk about coroutines in React. So they first appeared when work on fiber was going as a specific component type. So remember we saw that tags where you have all the different component types? You have two others that were coroutine component and used component. And the idea there as opposed to fibers was to give you, the developer, the full control of pausing and resumbing that. And by the way, there's this really interesting pull request that determines the idea and how they manage implement that and the whole thing. But the thing is that coroutines, per se, in React no longer exist for the face to face visual experiences, for example, optimizing those and memorizing, et cetera, they no longer exist. But I imagine it's going to be really interesting to see in which form this was going to come up in the future.

So, what we can do is talk about how coroutines as an abstraction might have influenced concurrent React, that is one of the most trending things we're talking about recently. So, if you remember this talk by Dan Abramov a few years ago, he was proposing this experiment where he has like this really CPU bound operation happening in the component and the component was lagging and et cetera. I want to propose a similar experiment. So, let's say we have this resourceful operation and that's the regular JavaScript function that basically iterates up to a million and then it sums the values and returns a string. Just think of it as any CPU bound operation. It can be for example, cracking some password. And then you have the resourceful component that's just using that and rendering the result. So, if we try to simulate that you'll see that you can start typing but it's going to start lagging to a point that your input field is going to be unresponsive and then you just crack the whole main track. And that's a really bad user experience.

For the next experiment, I wanted to recreate the same example as we had a coroutines-based scheduler. So, this is the code we have. I'm going to modify that a bit. And the key part you will see is that now I have a generator function. My resourceful operation is now a generator and I added this while true. I know it sounds hacky but I just wanted to use in the very beginning of the execution. And now I created this instance of a new scheduler and I'm passing my heavy operation. Let's see how this looks like, the actual code. So, I can start typing and you see, of course, it's suspensing because this scheduler is suspense ready. And you see it's suspense while it's performing but it doesn't lag at all.

6. Scheduler Code and Effect Handlers

Short description:

You see no issues with user experience. The scheduler code is only four lines long, with three different states: idle, pending, and done. Promises are used to make it suspense ready. React's multitasking comparative model allows rendering to be interleaved with other tasks, including other rendering tasks. Updates can happen in the background without blocking the response to new input. The scheduler yields execution back to the main thread every five milliseconds, ensuring smooth animations. Rendering is effectively interruptible. Effect handlers allow running code in response to specific tasks.

You see no issues with user experience. And this is the whole source code of the scheduler I just shared. So, it's not even four lines. And I would highlight this part that is basically where I'm switching in three different states. So, it can be idle and then it can be pending and then it can be done. You will see I'm throwing some promises because I want it to be suspense ready so that you would see suspense execution. And what you can see is that... Wait, did we just did something that sounds like used transition?

So, let's go back to the original code. And let's now do this start transition that's out there in React 18, as you probably saw. Let's see how this looks. You will see that, yeah, it did like a bit in the beginning, but I have a really similar experience. So, yes, we did, using some coroutines magic. And when I start to think about, in React, there's no use of WebWorkers or WASM or anything for parallelism. So how does React feel like this? So, what we have is this multitasking comparative model, where you have, yes, you have one single rendering thread, but it's interruptible. And rendering can be interleaved with other tasks. And also, other tasks could be other rendering tasks. So, in our example, it's like this. We had this original rendered task, and then we had this user input that of course has high priority, so that the UI is responsive. And then you have the right priority to handle test, but then you can resume the original And the cool thing is that any update can happen in the background. So, it would block the response to the new input. And the scheduler isn't smart enough to switch to the more usable one, then after it finishes, resume the other one you had. And my favorite fact about that is that it yields the execution back to the main thread every five milliseconds. And the first time I figured this out, I was like, OK, but why five is this like, those magical CSS numbers we use sometimes? And it's not. Actually, the thing is that it's the smaller thing you can fit in a single frame, even on 120 FPS devices. So that's why it feels like it doesn't block animations. And to be honest, the second thing is that most of the individual components, they don't take longer than that. It's not like we, on a daily basis, have to iterate up to a million in our components or anything like this. So in practice, yes, rendering is effectively interruptible.

And one of my favorite parts, effect handlers, so an overview for that is I was Googling that when I first saw it, I saw that basically effects are this thing that asking the call environment to handle a particular task. And when an effect is used, the nearest effect handler is called and then it allows you to run some code in response to this.

7. Introduction to Algebraic Effects in JavaScript

Short description:

Abramoff's post on algebraic effects in JavaScript code is really interesting. It uses imaginary JavaScript code to demonstrate the concept. The code sample shows how regular components and functions can be used to perform and handle effects. Instead of using throw and catch, the code uses perform and handle to manage effects. The resume width allows jumping back to the point where the effect was performed, making it useful for tasks like fetching data or logging.

Then Abramoff has this post that's called algebraic effects for the rest of us that's really interesting. And the code sample he uses, this is not JavaScript code, this is like imaginary JavaScript code. And what you're doing here is just we have a regular component, we have a regular function, we are getting this name and we will see this perform toward. And then this handle effect, so we are performing some effect and then we are handling. And if we think a bit, this sounds like throw, try, catch, but instead of throw we have perform and instead of catch we are handling that effect. And then this resume width basically lets us jump back to where we performed the effect. So this could be, for example, fetching something from a database or logging something.

8. History of Effect Handlers in React

Short description:

Effect handlers in React have been used throughout its history, starting with the layouting algorithm. They were experimenting with effect handlers to redefine the way React handled layouting. The idea of effect handlers was also used when rebuilding the context API in React 16.3, but issues with memoization and optimizations prevented them from using effect handlers. However, it is still an interesting concept to explore.

So effect handlers in React, they appear a lot throughout the whole history. So it all started with the layouting algorithm. So years ago, yeah, you can check this out. It's the whole thing, but to summarize, they were experimenting with that with constructions based on effect handlers to redo the whole way React was layouting. Fast forward in time when they were rebuilding the context API, so if you think about when React 16.3 was out, we had a brand new context API. When they were experimenting to create that, they also used the idea of effect handlers to build those. But again, issues with memoization and other optimizations prevented them from shipping that with effect handlers. But still, it's really interesting to check this out.

9. Handling Side Effects in React Components

Short description:

Again, handling side effects inside a component. A proposal by another core team member. Similar pattern, but instead of throw/catch, it catches effects. Components can suspend rendering by throwing a promise, caught and handled by the framework. This mimics effect handlers using the throw, handle, resume pattern in React components.

Again, with handling side effects inside a component. So this one is a proposal by another guy from the core team. A really similar example. And again, where you have the same pattern, but instead of throw rays, instead of catching, catching effect. Now, my favorite part about that. Who here has ever built a suspense ready API? So you're building an SDK, and you want people to use that with suspense. Oh. So I would recommend you to check this one, for example. That's React cache. But it doesn't have to be React cache. Just check any suspense ready API you use. For example, React fire or whatever. You will see the same pattern. That is a component is able to suspend the rendering by throwing a promise, which is caught and handled by the framework. And this sounds hecky, but actually this was the way they had to mimic the effect handlers. And how? Because you have the same throw, handle, resume pattern, but in the form of React components.

10. Conclusions on React Fiber and its Implications

Short description:

React fiber was a rewrite of React, focused on giving more control for low-level execution. React addresses the lack of resources at the language level by implementing alternative solutions. Understanding these internals allows us to come up with our own abstractions. React is not reactive but feels more and more concurrent. React is a democratic agent of spreading knowledge. Don't always trust all speculations and future predictions. Thank you for being here.

A few conclusions on top of that. So I guess the first one is, yeah, React fiber was a rewrite of React, the whole React core, focused on giving more control for lowlevel execution. Where we have fibers as this cooperative way to handle execution in lowlevel, and we have algebraic effects as a way to handle effects where they and their behavior are independent.

The second thing we can see is that React tries a lot to address the lack of those resources at language level, because JavaScript doesn't have them, by implementing alternative solutions time we checked them, we thought okay, this sounds like a hacky solution or a workaround, but no, it's because the language is still evolving, and it lacks resources, and those are creative ways of having them. By consequence, we can see that understanding those internals and the rationales behind them allows us to come up with our own abstractions. example, the pattern matching thing or the Cool Routines-based scheduler that not only was responsible but improved a lot the performance of our component in the example.

For the next conclusions, I'd like to mention this talk by Rich Harris from years ago. It's called rethinking reactivity, and in this talk, he explains a whole thing of why React is not reactive, and I think he's right. It's not reactive, but it feels more and more concurrent, and that's amazing. For one of my last ones, I love this tweet. It's like years and years ago. It was by Gisela Mahosh, and he said that React is such a good idea that we would spend the next decade exploring its implications and applications. I couldn't agree more because the fact that we are here, a lot of people discussing all of those concepts because they all somehow relate to React, shows that React is this democratic agent of spreading that kind of knowledge that's not so popular in the front-end world. So I really love that. And for my last one, I have this picture. And people say that a picture is worth 1,000 words. So this is me eight years ago in an iOS meetup, telling iOS developers that Ionic or Angular would be the whole feature of development. So I guess the last conclusion is don't always trust all of my speculations and future predictions. These slides are going to be available on my Speaker Rack profile. And that's all. Thank you so much for being here. And it feels great to have those events back. Thank you. Thank you so much. Now, before people rush off to lunch, I have this massive cup filled with React coins. Remember, if you collect the most React coins, you can get a prize. Stick around. You'll find out how to get these off of me. But thank you so much for your talk. I really enjoyed it.


Questions on Throwing Promises and Try-Catching

Short description:

Can you use React hooks that store data on the fiber in the same stack frames? Try-catching is not an expensive operation in React. The difficulty lies in abstracting the way you handle effects. This was a reason why the proposal for algebraic effects didn't progress much.

Really enjoyed it. Let's jump into some of those questions. So when throwing a promise for suspense, can you also use React hooks that store data on the fiber in the same stack frames? I'm not sure if I get this one. It says to rephrase, maybe. We'll come back to that one. But let's jump over to the next question about try-catching being an expensive operation. As far as I'm aware of, no. To be honest, I'd never check like benchmarking on that, to be honest, but as far as I'm aware, no. Probably this question was because of the things I mentioned. The difficulty of memorizing stuff and etc. But it relates more to the whole way you abstract those than to try and catch something itself. For example, this was the reason, for example, that the proposal for jabraic effects didn't move forward a lot because we got to the same thing that it was difficult to optimize that, but not because of the whole nature of trying catch. Nice, nice.

Learning Resources and Comments

Short description:

To learn more about Fiber, you can start by engaging in discussions with the IRFCs and exploring the PRs and discussions, especially the older ones. Additionally, you can check out other repositories like React Basic and the IRFCs repos to gain a better understanding of the historical context. It's also beneficial to draw inspiration from other languages such as F, Clojure, or other Lisp languages that have worked on similar concepts. Lastly, don't forget to connect all the pieces together and explore the interesting work on caching and suspense.

Now, we don't have any more questions, but I just want to learn. I personally have not actually learned a lot about Fiber, so I was listening to your talk and it's so much that I would like to go and research and learn more about. Where should I start looking? One of my favorite ways of doing that is actually talking during discussions to all the IRFCs and what they've been doing since 18, a really good work with the RFCs, and etc., but go through the PRs, discussions, especially the old ones because you see how they evolved to the point it is now. You will understand the context, that's one thing, and go through other repos like React Basic and the IRFCs repos. There are repos outside of the main one but they have a lot of content that helps you understand the historical context and how they got to this point. That's one thing. The other thing is check inspiration from other languages. For example, there is a language called F and it implements out of the box this whole idea of effect handlers. It's called F. Check how those other languages abstract on top of that. For example, for the thing of homo-iconicity, Clojure or other Lisp languages. So, trying to see how other languages who did a lot of previous work on that abstract on top of this and then connecting to what you see of the previous work on the React team and try to piece them all together.

Nice. Now, this next one looks more like a comment than a question about Drupal throwing values instead of exceptions. I'm going to guess we don't need to feel too bad about React. Yeah. I didn't know to be honest. I mean, I've done PHP in the past but I didn't get to that point. But that's interesting. And by the way, I'm not sure if that was a post or only a comment in a PR discussion but then Abramoff was kind of mentioning that it's a pity that today we see only suspense as throwing promises because it's way much more than that. I know that there's a lot of interesting work on caching for example that pieces together with suspense. So I myself was one that was making jokes about throwing promises for a while. But yeah, it's interesting to see that. Nice. Thank you so much.

Now before you go, folks, I have literally maybe a couple hundred React coins. I'm going to give them over to Matheus. Wow. Because if you go over to Matheus, you can grab some of these React coins from him. However, you need to ask him a question. So Matheus, they can ask you a random question, any question, I'm throwing you under the bus here. It could be about fiber, it could be just about your time speaking. And go and talk to Matheus over at the Q&A booth. Sure. And see him before you go to lunch. Not only this, but I didn't get to put it on the slides, but I did trade stickers as a side. Trade stickers, yes. Me and him traded stickers at the booth. Definitely check him out for cool stickers.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
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
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
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 2022React Summit 2022
20 min
Routing in React 18 and Beyond
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.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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
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
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
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
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