React Concurrency, Explained

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

React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

23 min
02 Jun, 2023

Video Summary and Transcription

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.

Available in Español

1. Introduction to Concurrent Rendering

Short description:

1,489 days! This is how much time passed between Dan Mobromov's first review of what back then was called Time Slicing and Direct18 release which finally made these capabilities available for everyone. In these 1,489 days, Time Slicing went through a bunch of rebrandings, several API changes, and today became known as concurrent rendering. Now, concurrent rendering generally includes two features. Hooks like useTransition and useDefaultValue and improvements around suspense and hydration. There's also a third performance feature that Direct18 shipped, better batching of updates, but it's not part of concurrency. So when I first tried working with these concurrent features, especially with stuff like useTransition, it sometimes really felt like magic in terms of how it optimizes the app. So today, I want to show you folks what actually happens in the app whenever you use the first, the most foundational performance feature, useTransition, and how Rack achieves this magic, which is actually not magic at all. So let's dive into useTransition, useDefaultValue hooks, and to show them, let me show you a slow app.

1,489 days! This is how much time passed between Dan Mobromov's first review of what back then was called Time Slicing and Direct18 release which finally made these capabilities available for everyone. In these 1,489 days, Time Slicing went through a bunch of rebrandings, several API changes, and today became known as concurrent rendering.

Now, concurrent rendering generally includes two features. Hooks like useTransition and useDefaultValue and improvements around suspense and hydration. There's also a third performance feature that Direct18 shipped, better batching of updates, but it's not part of concurrency.

So when I first tried working with these concurrent features, especially with stuff like useTransition, it sometimes really felt like magic in terms of how it optimizes the app. So today, I want to show you folks what actually happens in the app whenever you use the first, the most foundational performance feature, useTransition, and how Rack achieves this magic, which is actually not magic at all. So let's dive into useTransition, useDefaultValue hooks, and to show them, let me show you a slow app.

2. Performance Issue with Filtering Nodes

Short description:

So this is a basic not-taking app that experiences slow performance when filtering nodes. The UI freezes and lags, causing delays in updates. By analyzing the app with DevTools Profiler, a spike of CPU activity is observed, with a keydown event taking a significant amount of time to process. The event triggers a series of React function calls, resulting in the rendering of multiple components. This re-rendering process is a stop-the-world operation, causing delays in user interaction. To address this performance issue, the developer seeks suggestions on how to solve it, specifically in the context of React 17.

So this is a basic not-taking app. Oops! Oh, wait! Oh, no! I—I, hold on. Sorry. I— This. Yes. Ah! Yes, we're back. So this is a basic not-taking app, and it has a list of nodes which you can filter. And if you try to filter these nodes, the app will get slow. You can notice it if you look at this cube of ice that spins. It's a spinner that freezes when the app freezes, when the page freezes, and, well, spins when it's not frozen, kind of like opposite of ice.

If I try typing, if I try filtering nodes, if I try typing the F letter, for example, you can notice how the spinner freezes for a second or two. If I try typing more, you could see how the app just lags as I'm typing. So you can't really feel it, because I'm typing behind the keyboard. But you could see how I'm typing, and the app feels really, really slow. The UI updates, happens with the delay, and the app just freezes for a second or two.

So now, whenever I have a performance issue, what I like to do is I like to open DevTools Profiler, DevTools Performance, and try to record what's happening in the app with the performance pane. So in this case, if I click record, and try typing, and stop recording, I'll see that what's happening in the app is I have this huge 500ms spike of CPU activity, and if I zoom into that spike of CPU activity, I'll see that I have a single keydown event that takes 550ms to process, and underneath that event, there are a whole lot of React function calls.

So now, if I were to debug this a little deeper and try to figure out what's going on, I would see this. So here's what happens in the app. What happens is I'm typing into the text field, the filter inputs, that calls this set filter function, which is just a useState hook, that, in turn, changes the state in a bunch of components, and that causes React to render all these components one by one until it's done. And because we have a lot of components, a lot of node buttons, that takes a while. So this re-render is a stop-the-world operation. Nothing can happen until React is done. If a user tries to interact with the app in any way, they'll have to wait until the re-render is done. If re-rendering the app takes two seconds, the user will have to wait for two seconds. This is how React 17 works, React 16 works, even React 18 works out of the box. A pretty standard JavaScript blocking behavior.

Now, let's take a step back. We have a performance issue, right? I'm typing to the text field, and that text field goes to a list of nodes to re-render, and this re-render is blocking and expensive, which slows the app and slows the whole typing process. So my question to you, to you folks, if you were a developer of this app, and this app was using React 17, how would you try to solve this? There are multiple solutions here, what would you try? Sorry? De-balancing.

3. Improving Performance with React 18

Short description:

De-balancing, throttling, virtualized DLS, React Memo, optimizing components, virtualizing the list, and React 18's non-urgent updates are all solutions to improve performance. With React 18, updates can have a priority, and non-urgent updates don't block the app. Let's switch back to the code. The nodes list component controls the filter inputs and buttons. Updates are considered urgent by default, but can be made non-urgent using React's performance APIs.

De-balancing, throttling, yes. Oh, it's really hard to hear from here. Virtualized DLS, yes, another great solution. Any other ideas? Good, so yeah, there are multiple things we could try here. We could try using React Memo if the components render unnecessarily. We could try optimizing the components themselves, maybe the components are expensive for some reason, we could try virtualizing the list to only render the items that are visible on the screen, we could try debalancing or throttling, and these are all great solutions and you can even combine them, but what React 18 does is it introduces another solution to the mix, making updates non-urgent.

What does this mean? So with React 17 and below, every update that happens in the app is considered urgent. If you click a button, React has to handle that update immediately. If you type into the filter input, React has to render the list of nodes immediately. With React 18, your update can now have a priority. Every update you make in the app is still by default urgent, but what React now also supports is non-urgent updates, and non-urgent updates almost magically don't block the no matter how long they take. Let's see how this works. Bear with me. I lost my mouse. Here's my mouse. Oh no, yes.

So, let's switch back to code. Let's switch back to the main mouse. It's kind of confusing, if I put my mouse here, or like this demonstration, it's also duplicated there, so I can never know where the mouse is. Anyway, so, let's look at the code. This is the code of the app that we have here. This is the code of this nodes list component that we have on the left. In the nodes list component, we have the filter inputs, and we have the list of buttons. So, here's the filter input that we have in the app UI, and here is the list of buttons. All this UI is controlled by the single filter state field. Whenever I type into the field, this filter field updates, and the UI re-enters. Now, this update, by default, is considered argent. To make an update non-argent, what I need to do is to use one of three new React performance APIs, React start transition, React use transition hook, or React use the first value hook. They're all pretty similar. They do more or less the same thing.

4. Using the useTransition Hook

Short description:

I'm going to focus on the use transition hook from React. It returns the is pending flag, indicating an ongoing transition, and the function start transition, which marks updates as non-urgent. I'll split the state into two parts: filterInput for immediate updates and filterValue for non-urgent updates. By cloning the useState hook, I'll create setFilterInput and setFilterValue. The filter input state will control the input, while the filter value state will control the list of nodes. I'll pass these states accordingly and update them using the set state hooks.

So, I'm going to focus only on the second one, use transition. And so, here's what I'm going to do. First, I'm going to go to the very top and import the use transition hook from React. Second, I'm going to call this use transition hook in the code, and the use transition hook returns two values. No, GitHub copilot, you are wrong. It returns the is pending flag, which indicates that transition is ongoing, and it returns the function, start transition, which lets you actually mark some updates non-urgent. Then, the third change that I'm going to make is, and bear with me, I'm going to take this piece of state, and I'm going to split it into two bits of state. Oh, no, wrong buttons. If you look at this filter, you will notice that it controls two parts of the UI, right? It controls the filter that we have here, and it controls the list of nodes that we have here. So the thing about this bit of state is that ... Or the thing about this UI is that one part of this UI is a part of the UI that we want to update immediately, urgently. It's the filter input. Like whenever the user is typing into the filter, we want to reflect the change immediately, we want to update it immediately. But the list of nodes can be filtered with a delay. It can be updated non-urgently. So what I'm going to do is I'm going to take this bit of state and I'm going to split it into two bits of state. One that's going to be updated urgently, and another one that's going to be updated non-urgently. So I'm going to clone the use state and call the first ... Let's call it setFilter. Sorry, let's call it filterInput and setFilterInput, because it's going to control the input. And the second one is going to control the list of nodes, so maybe I'll call it filterValue and setFilterValue. Now I'm going to take this filter input state and pass it here, and I'm going to take this filter value state and pass it farther down the code. Oh no, hold on, this, this, this. Oh yeah, and the one on the top. Paste here, paste here. Done. And now I also need to update these states, right? So before I was, I had like one set state hook. Now I'm going to have two, so I'm just going to value, okay, that was, that was a spoiler from GitHub quality. SetFilterValue. Value, yep.

5. Improving App Performance with Non-Urgent Updates

Short description:

So, we split the state into two bits of state. However, the app still lags when typing into the filter. To address this, we mark the setFilterValue call as non-urgent by wrapping it with StartTransition. Now, the list of nodes updates without freezing, allowing uninterrupted user interaction.

So, and the closing bracket. So what we did here so far is we, we did, like, we did pretty much nothing. Like, the only change we did so far is we take, took this bit of state and we split it into two bits of state. And so, which is pretty, well, it doesn't, doesn't make any sense yet.

So like, if I try typing to the filter, you'll notice that, like, it's still, it's still slow. It's still lagging, right? I'm pressing F and the IceCube lag, like stuff's spinning for a second. But that's because both of these state updates are still urgent.

So what I'm going to do now is I'm going to make one last change. I'm going to take my setFilterValue hook and I'm going to mark it, setFilterValue call, and I'm going to mark it as non-urgent. And I'm going to do this by wrapping it with StartTransition. And so, look, the only change I made, I wrapped the filter state with StartTransition. And now if I try typing into the filter, you'll notice that the list of nodes still updates, but the app does not freeze at all, the ice cubes keep spinning uninterrupted the whole time. It's batterithmost.

6. React's Concurrent Rendering and Drawbacks

Short description:

I can type as much as I want and it updates perfectly. So it's like magic. It's so cool. So now could anyone guess how this works? The way this works is given back control. So what React does it starts rendering the app, and then it gives back control to the browser after every frame. In DevTools, this was the old behavior, right? I pressed the keyboard button, and the main thread was blocked for 500 milliseconds. But if I zoom into that spike, I'll see that my key perceived when that happened when I typed the F letter, it takes now just 15 milliseconds, and here React performs the Argent update immediately, no matter when the click happens. This is how React 18's concurrent rendering and this is how it works under the hood. Now, let's talk about drawbacks because, of course, there's no free lunch. The first drawback is that known Argent updates take longer. React has to yield the control back to the browser all the time and that introduces some delays.

I can type as much as I want and it updates perfectly. So it's like magic. It's so cool. So now could anyone guess how this works? How does React do this, do you know or are you guessing? Promise? No? Maybe in that direction. Go ahead. I would say it just queues it and whenever it's free it does something and then it spins again. But did you notice that the ice cubes kept spinning the whole time? When you do something, when you click on something immediately so whenever React dims it's able to do so, it will run that phase of code. Kinda yes, but... It's just a guess. Yeah, yeah, okay, yeah. Any other ideas? I'm sorry for live listeners this is probably the boring part. Go ahead, yeah. Is it sitting out? Sitting out? It's a part, but no. So the way this works is... Sorry, wrong slide. The way this works is given back control. So what React does it starts rendering the app, and then it gives back control to the browser after every frame. Let's see how this looks in DevTools. So, in DevTools, this was the old behavior, right? I pressed the keyboard button, and the main thread was blocked for 500 milliseconds. The React started rendering and React kept rendering for 500 milliseconds. So what React is going to do now, or what React is doing now is if I type any single letter, and then stop recording, and see what happens, I would still notice a single spike of the CPU activity, right, in the top. But if I zoom into that spike, I'll see that my key perceived when that happened when I typed the F letter, it takes now just 15 milliseconds, and here React performs the Argent update immediately, no matter when the click happens, because every known Argent updates will typically be blocking the main thread only for five or 10 milliseconds. This is how React 18's concurrent rendering and this is how it works under the hood. Now, let's talk about drawbacks because, of course, there's no free lunch. The first drawback is that known Argent updates take longer. React has to yield the control back to the browser all the time and that introduces some delays. So if I switch back to the browser, I'm not going to reproduce that now, but I just took this app and I made the recording with start transition and without start transition. So in the case without start transition, when I was recording it an hour ago, this key press event took 473 milliseconds to render, and it blocked the main thread for the whole time. When I added start transition, the main threads stopped being blocked, but the whole update, like rendering all the components took longer. It took it, can you see it? 582 milliseconds.

7. Drawbacks of React Concurrency

Short description:

React concurrency is slower for non-urgent updates, more CPU expensive for all updates, and does not help with expensive components. However, if you're willing to deal with these drawbacks, you'll get the almost magical behavior of rendering something huge without slowing the page.

So 100 milliseconds longer. So this overhead, it's not constant, it depends how many components you're rendering, I don't know, et cetera. It's not like it's 100 milliseconds longer every time, or 20% longer, but what you see here is because Rect has to give the control back to the browser every time, the whole update finishes later. Maybe that's okay because it's marked as non-urgent, but that's a drawback to keep in mind.

The second drawback is this extra complexity does not come for free. To make concurrent rendering possible, Rect had to make its architecture much more complex. It introduced RectFiber, which by the way, the next talk on that stage is going to talk about. Go check it out. It introduced concurrent rendering checks. All this stuff takes a toll on the CPU, and in fact this is one of the reasons Vue and Preact straight refuse to implement anything similar to concurrent rendering. Both Vue and Preact believe that it's unlikely any real world apps will benefit from concurrent features. Like Marvin from Preact, for example, says, it's still up in the air whether concurrent mode is something that will benefit apps at all, even for React. Or Evan from Vue says, the demo Rect team showcased, it's so contrived that it will most likely never happen in the actual app. And I'm showing screenshots from 2019 and 2020, but based on Twitter conversations, nothing has changed since then.

Now, the React team, however, seems to play a long game and is explicit about it. I'm not sure if it's still on Twitter because that's where all the real documentation lives nowadays but Dan, for example, in this tweet says, this unlocks many abilities that weren't possible. Time slicing is just a nice bonus. And one of the things that the concurrent features will unlock is the upcoming off-screen API, which allows for rendering invisible UI parts in the background, and it does require concurrent rendering to work, to not block rendering when it's rendering, rendering, rendering. Anyway, there's another drawback slash pitfall. React concurrency does not help to optimize expensive components. If you look at the React's primary rendering loop again, you'll notice that should yield to host this function that checks whether React has to give the control back to the browser, it's only called after every render, right? So like the performing unit of work function, it takes one component. It starts rendering it. And then only once that rendering is complete should it yield to host checks whether React should give the control back to the browser. So if any single component takes, for example, not five but 500 milliseconds to render, the main thread will still be blocked for the full 500 milliseconds, even despite this update being marked as non-urgent. And this is the third drawback of React concurrency. Drawback slash pitfall. So to summarize, React concurrency is slower for non-urgent updates. It's more CPU expensive for all updates. It does not help with expensive components, but if you're willing to deal with all these drawbacks and pitfalls, you'll get this almost magical behavior of rendering something huge and not slowing the page at all. Is this a meme? Maybe this is a meme.

8. Identifying Need for useTransition in React

Short description:

If your app is slow and there are multiple small components causing the slowness, use useTransition. It works similarly to throttling or bouncing, but without any delays in rendering.

Thank you. Okay, so we have some questions. Yes. First of this, how can I know or judge that I need to use useTransition? What are some signals or signs that you should look for? So good question. I don't have an intuition about this yet to be clear. But I'm going to try to answer. If your app is slow, and if you see that it's like if you try to run a rectProfiler and you see that it's not because there's like some single expensive component, but a bunch of small ones, which is like pretty much how typical happens. And you know that like, you can delay some parts of the UI, then you would use it or actually a better transition. So if you're thinking of using throttling, or bouncing, try startTransition first, because it works pretty much in the same way but it's better because it does not delay anything. It does not delay rendering by like a second or two seconds. Nice.

QnA

Updates, Cancellations, and APIs in Libraries

Short description:

Why do updates give unexpected incomplete results when writing tests? How are deprecated updates cancelled? How can you benefit from these APIs if your non-urgent update happens in a library, like React Query, for example?

Thank you. Why do updates give unexpected incomplete results when writing tests? Like, is there a scenario in here when you're doing automated tests and you expect something to happen on screen, maybe on tick? I have not... Yeah, I don't know. I guess like good tests, they typically wait for like an element to appear on screen. That's not going to affect these tests. Yeah, if there's tests that uses the timer then I guess that might affect them a little. Yeah, that's true.

Wait. Next one. Let's see. Too many questions. How are deprecated updates cancelled? So if you have multiple... OK, yeah. That's a great question. So Rack just cancels them. I don't remember the exact mechanics. But if I type F and Rack starts rendering this huge list of notes, and then 100 milliseconds later I type another letter, then Rack will just throw away the first render that's been on progress. It will start rendering the second render. So it's smart, it's good about it, it just stops the work as soon as it can. Nice.

How can you benefit from these APIs if your non-urgent update happens in a library, like React Query, for example? Sorry? How can you use these APIs if the... Urgent update happens? In, like, a library, in a React Query, for example. That is a good question. So I don't know. The next API you need to wrap like whatever function you have that changes the state, you need to wrap it with startTransition. It does not have to be exactly this at state callback, it could be 10 layers of intermediate functions. But if React Query... I have not used React Query. So if React Query gives you some callback that changes the state, that you could wrap with that, then that's good. If it says the state internally, then no.

Using Deferred APIs and Handling Urgent Updates

Short description:

Check out useDeferredWidgetHook and useDeferredValue as alternative APIs. Libraries like React Query don't automatically handle urgent or non-urgent updates. If an urgent update occurs while non-urgent updates are in the queue, React will prioritize the urgent update. If the urgent update affects non-urgent state, React will re-render the non-urgent state from scratch. If it affects other parts of the UI, React will continue where it left off. Thank you for having me!

Also check out the useDeferredWidgetHook, because it's a different API, and if you can't transition, maybe useDefersedValue will help you. Yeah. Do you know of any libraries that are actually implementing this internally? Like, are there, for example, flags for React Query that you could instruct React Query to do the right thing automatically for certain sets of data? I don't really, and I think the reason for this, there's a good reason for this, the library does not know which parts of the UI are urgent or non-urgent. It's up to you, to the application developer. True.

Okay. So what happens if an urgent update comes in while non-urgent updates are still in the queue? Also great, yeah. So then an urgent update is going to be stopped. React will run the urgent update immediately. And then actually, not sure, like, I think the, so, don't quote me on this, but, my understanding is, if the urgent update changes the non-urgent state, then like React will start rendering the non-urgent state from scratch. If it affects some other part of the UI, then React will just continue what it, like where it posts. I think, don't quote me on this, but I think that's how it works. Nice. Thank you. I will go and tweet it immediately. You said this. OK.

I think all of the other questions here are pretty much answered already. So I think that's all. Thank you so much. Thank you for having me.

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
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 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
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.

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