Patterns for Performance

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more

When working with React it is important that we use the right tool for the right job. If not we will be missing out on the best performance and developer experience. While optimising AG Grid React Table we discovered a number of patterns that made significant improvements to the tables performance.

This talk has been presented at React Advanced 2023, check out the latest edition of this React Conference.

Watch video on a separate page

FAQ

The talk addresses the issue of grid performance, specifically slow resizing when using custom cell renderers in Azure Grid and how to optimize it.

Azure Grid ensures robustness by enabling direct style manipulations and by implementing solutions that work efficiently even if developers do not use memoization for their components.

Using `useLayoutEffect` in server-side rendering can cause issues because it does not execute until the client-side JavaScript loads, potentially leading to mismatched content or layout shifts.

Azure Grid plans to introduce a feature that allows the state of column widths to be saved and restored, facilitating persistence across different sessions or tabs.

Custom cell renderers in React allow developers to use functional or class components to render content within each cell of a grid, enabling the customization of cell content.

Azure Grid focuses on creating the best JavaScript or React data table in the world, offering both free and enterprise versions of their product.

Common mistakes include implementing expensive operations within renderers which can degrade performance, especially when rendering large amounts of data.

Azure Grid improved resizing performance by using memoization to prevent unnecessary re-renders and by directly manipulating the DOM for style updates, reducing the overall scripting time.

While `useEffect` runs asynchronously after the DOM updates, `useLayoutEffect` executes synchronously before the browser paints, allowing immediate DOM manipulations without waiting for the next paint cycle.

Using a ref callback allows developers to run code specifically when a component mounts or unmounts, ensuring that actions such as DOM manipulations are tied directly to a component's lifecycle.

Stephen Cooper
Stephen Cooper
28 min
20 Oct, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses patterns for performance in React development, including addressing slow resizing in custom cell renderers. It explores optimizing React render performance by reducing excessive re-rendering and using direct style updates. The use of layout effect and callback refs is also highlighted as techniques to improve performance. Additionally, the Talk mentions the AG Grid and TanStack Table libraries, as well as upcoming features like grid state restoration.
Available in Español: Patrones para el Rendimiento

1. Patterns for Performance in React Development

Short description:

I want to talk to you about patterns for performance in React development. We'll discuss the issue of slow resizing in custom cell renderers and how to resolve it. Our mission at Azure Grid is to create the best JavaScript or React data table in the world. We'll take a benchmark of the standard grid to understand its behavior when it works fast. The grid resizes smoothly with a high number of renders but without any slowdown.

♪ ♪ So, yeah, I want to talk to you about patterns for performance, because I guess we've already seen some talks today which have been talking about performance, and as a React developer, that is a key thing that a lot of us are always, I guess, important to us, important to our users. So that's why I want to share this with you today.

As I do work for Azure Grid, there's going to be some grids featured in this talk. So, can you say which of these grids is better? We've got the top one where you're resizing and it's, you know, jumping along, or you've got the bottom one where you've got this smooth resizing. So I think it's obvious which ones our users would want to use and which you would want to work with. And so this is something we're going to dive into and say how we solved this issue.

So, as you already know, I work at Azure Grid and our mission is to create the best JavaScript or React data table in the world. So, you know, we've got a free version. We've got enterprise versions. So do come and find out more about this because we think it's a brilliant product and it's getting better and we are really heavily investing in our React component. So we hope you can try it out, but that's enough about Azure Grid. You want to know about performance.

So to, I guess, give us a story for this talk, we want to have this reconstruction where a user has started using Azure Grid, very old version, which doesn't have this issue anymore, and they said, oh, you know, when I use this custom component, the grid does this really slow resizing. So they think, oh, okay, but they also say, well, it's when they're using a custom cell renderer. So just to give you, I guess, the background you need, custom cell renderers are a way for you as a React developer to give our grid a functional component or a class component and say render this within every cell. So here we've got a weather table where instead of numbers, you've got pictograms based on how many days of sunshine. And that would be your own React component. So in the use case, we've got they're displaying a total. So they might have a renderer like this, where in the body of their renderer, they've got some really complex logic, which is really slow. And then they're just returning a value. I mean, this isn't going to be slow, but just go with me and hopefully it'll demonstrate what we're trying to show here. And then to use this cell renderer, they pass it to the grid in this way. We'll find that on their column saying, well, actually render this with my renderer and pass it to the AG grid component. So we'll come back to this stage and we think, okay, how are we going to resolve this issue? Because we haven't noticed it yet. If we want to diagnose why it's slow, we need to just take a step back and think, well, in the normal case, when it works fast, how does the grid behave in that situation? So we take a benchmark. This is the standard grid, no cell renders, and it resizes really smoothly. We're going to use the React DevTools profiler and we'll profile it and we get something like this. So while we're resizing the column, we've got 254 renders going on. So that is a lot of renders, but they're really fast renders. So that's why you're not really seeing any slowdown despite the fact that there's that many renders.

Read also

2. React Render Performance

Short description:

React can render a lot of times without your user and your application slowing down. But if the renders are slow, it can cause issues. Each renderer now takes 28.9 milliseconds and blocks the main thread. This results in a jump in rendering and the browser not being able to repaint enough times.

So it's not always more renders is bad. It's also, well, how slow are those renders? Because React is fast. React can render a lot of times without your user and your application slowing down. So now let's go back to the user's case where they do have this issue, and we'll do the same thing. See, now we've got less renders, but each of these renderers, instead of being less than a millisecond, are now, what does it say, 28.9 milliseconds to render that total renderer. And each one of these is now blocking the main thread. So React, in this same time period where we're pulling the icon three size, is only able to render it 10 times. And so that's what's giving us this, you know, jump, jump, jump, because the browser isn't able to repaint enough times to keep up with it.

3. Optimizing React Render

Short description:

So why is it slow? The cell component re-renders many times. We introduce a total renderer, which has an expensive render, blocking the main thread. The initial implementation had a state for the width, causing frequent re-renders. Using Memo helps skip re-rendering the child component, but can we do better? Profiling with Chrome dev tools reveals excessive re-rendering, even with Memo. What if we don't re-render at all? The width only changes the style property, so we don't need it in a state.

So why is it slow? Well, the cell component, it re-renders many times. And we saw that even without our custom renderer, that was still rendering a lot, but it was rendering fast. You introduce this total renderer, which is a child, so that's also being rendered a lot, but then it has an expensive render, which is now blocking the main thread. And so instead of all the fast renders, we've now got some slow ones, which is causing this behavior.

So why is it rendering so much? Well, so in the initial implementation, we had this, so the cell component had a state for the width. And so it was listened to this callback from our controller saying whenever the width changed, so when it's being dragged, it would call setWidth and set the state, and then React would re-render. So it's the standard kind of pattern of state re-render. And I think the talk two time before was, you know, also running in kind of these issues of how do we escape this pattern. Simple solution, Memo. You know, Memo lets us skip re-rendering the child component. So we can update our code like this. So instead of passing the value render directly in, we wrap it in Memo, pass it to the cell renderer, and that takes us back to the fast rendering. Now, if I stop there, that would be a very short talk, and I'm sure nothing new. But can we do better than Memo?

So let's profile it again, but now with the Chrome dev tools. So it seems like it's working fine. But if we take a closer look, when we're resizing, we'll see something like this. So there's lots and lots of these different actions where it's re-rendering as we're changing the side. And in total, it's about 81 milliseconds of scripting. And if we zoom in to each one of those spikes, what we can see is we've got AD grid code followed by some React code. And this is using the dev mode to give us slightly nicer, I guess, name. So we can see what React is doing. But what you can see is we've got AD grid doing something, it's painting, and then we've got React doing something. So this is, AD grid says this is what the width should be, and then we tell React, and then React takes that, re-renders, and does all this extra work. So Memo is still gonna be running comparison code. And the cell comp is still rendering. So even though we've stopped the child component re-rendering, which was the blocker, we're still actually doing potentially more work than we need to do. What if we don't re-render at all? And this is where it takes sometimes to look at our application code and think, well, what is actually changing here? So if we look at this line of code, the only thing that the width is changing is the style property. So we're not actually making any structural changes to the DOM. So when we see this, we think, well, actually, maybe I don't need this in a state. Maybe I can actually do this myself.

4. Direct Style Update and Initial Width

Short description:

We can access the DOM and change the style property directly, resulting in a significant performance improvement. This approach works even if the component is not wrapped in memo. However, there is a bug in the code that causes columns to flicker. To set the initial width, we can use the layout effect and the use ref as a callback.

I can access the DOM, and I can change the style property. So how do we get the reference to the div? Well, you know, you can use a ref, and you can set it on the ref, and we know that that's gonna give us a reference to that DOM element, which we are then able to interact with.

So then, within our callback we can use this effect to set up it on a net, and we directly change the DOM style. So we get the sole ref, we get the current one, and then for that style property, we're now changing the width. And this is gonna have exactly the same impact on our component as what React would eventually do after it had rendered, worked out what had changed, and produced the new output. So we can just skip all of that, and say, well, actually, the only thing which is changing is this. I'm gonna surgically change it myself. And now, if we re-profile it again with this change, we're down to 31 milliseconds. So it's a massive drop, because we've just said, well, I know what I'm doing, let me do it myself, use the browser, you know, reference it in the way that we can do. So now, when we're resizing, we've just got ag-grid code, and the browser is repainting.

So I think this is something which we do need to remember. We're working in React, but we're also working in the browser. And the browser has tools and ways for us to update things that we can use to good effect. And so this is like one example of where we can do that. And so we've gone from this with react-memo into the direct-style-update, which is giving us a much better user experience. And also, something to note here is that it's not only a better user experience if the user has remembered to use memo, this is now also going to work if the user hasn't, the developer hasn't wrapped their component in memo. So we've enabled our grid to be much more robust to however it's being configured. And that's something which is important because even if developers are making suboptimal choices as an application library, we want to try and give them the best opportunity for our product still to work as fast as it can do.

But we need to be careful. The code which we've shown so far actually has a pretty big bug. I don't know if anyone has any idea what that might be, but we'll see this. So we made these changes, but then suddenly the columns start flickering into place. So you load up your grid, and you can see all of them are overlined over the first one. So what's happening now is that we're using an effect. And an effect is run asynchronously after the browser has painted. So what we've got here is React is rendering all our columns, painting them to the browser, and then it's running the effect, which is then coming in and changing the style directly, which is why we've got columns all in one place and then suddenly they jump. So we don't want this, because this is even worse. So how can we set this initial width then? Because you can't just put it in a state and then have your direct style manipulation, because the next time it renders, whatever was in the state value is gonna override what you've done. So you're gonna have to work out, well, which one should I be reading and what's the source of truth? But we've got these two alternative approaches. So the first is use layout effect and then the use ref as a callback.

5. Understanding Use Layout Effect

Short description:

Use layout effect can hurt performance, but we're actually using it to improve the performance of our application. The key difference here is that use layout effect. It's like use effect, but it fires before the browser repaints the screen and it's synchronous. So any code you put in a use layout effect is going to block the browser painting.

So I love this. When I took this snapshot from the docs, it was like, oh, okay. So there's this pitfall. Use layout effect can hurt performance, but we're actually using it to improve the performance of our application. So you've got to kind of dig into, well, why could this hurt performance, but why in this use case is it actually helping us to have a better performance in our app? And so the key difference here is that use layout effect. It's like use effect, but it fires before the browser repaints the screen and it's synchronous. So any code you put in a use layout effect is going to block the browser painting. So this is why it can be a pitfall. So if you do have some expensive code, you know, put in there, it's going to delay the time that the browser gets to repaint. Don't know if I'm making that sense. Which is why most of the time it says use an effect because the side effects, they might be heavy. And so, yeah, you want the browser to paint and then you run those. You don't want to have to block that painting.

6. Using Callback Refs for Conditional Code Execution

Short description:

We swap use effect for use layout effect to fix the issue of the width jump. However, use layout effect has some downsides. It runs whether the cell is mounted or not and can be expensive. In strict mode, it runs twice. A better approach is using callback refs to conditionally run code only when the element is mounted.

But so we make the simple change. We swap use effect for use layout effect. We don't have to change anything else and now this code is running synchronously. So the width is applied before the column is rendered. So we don't get this jump. So this fixes it. So that's a viable solution for it. But there's some potential downsides and that's the use layout effect. It's going to be run no matter whether this cell is mounted in the DOM or not. So it could be conditionally rendered but the logic in this use layout effect because it's dependent on the component itself, if I go back you see it's got this, the empty dependency array. So whenever this component is first rendered this code is going to run. So if there is something in there that's slightly expensive, it's going to be run every single time. And also it runs twice in strict mode which can then mean you have to take other actions. And there's a good blog post here from Dominic about using avoiding effects with callback refs. And so this is then a pattern which I think is an even better approach to solving this problem.

7. Using Callback Refs for Dynamic Width Updates

Short description:

We can define a ref with a callback function that will only be run when the specific div element is mounted. This allows us to update the width dynamically without causing any renders. The callback should be wrapped in a useCallback to avoid unnecessary recalls. This approach eliminates the need for strict mode logic.

So we're all probably very used to having use ref in our code where you define the ref and then you pass it to the div element and then you know that that ref is going to be defined. But if we inspect the type of that closely there's also a callback. So we can actually give this a function. So we define a ref as usual because we still want to be able to reference our div element for the cell. But then we define a callback. So we're going to say set ref and this callback will receive a reference to the div or null. And you pass that callback to the ref. And the nice thing about this is that this callback is only going to get run when this specific div element is mounted. So if things are conditionally rendered this, the code that you set up in your callback for this reference is only going to run when the div is actually mounted. And then it, you can get null because React will call this again when that element is unmounted. Now it's crucial that you use, you wrap this in a useCallback because if you don't then on every render this React will recall it with a new ref. So the callback there is essential. So then if we come back and update our code for our cell reference, it will look something like this. We define our reference and we set up this callback. And now within this callback we do the same code where we listen to our cell controller for the width changes and apply the style directly. And this now works, runs synchronously to start with and then also enables us to update the width dynamically or directly without causing any renders. So I think I ran through these. You call it, ref with the elements be mounted, it's gonna be called again when it's unmounted, run synchronously which is key for us and it only runs once. So you can avoid some of the strict mode logic if you need to.

8. Final Takeaways on Performance and Optimization

Short description:

No matter what the user or developer passes in, we are now guarded against slow renders. React is fast, and you don't have to prematurely optimize everything. With Agigrid, we wanted to make it as fast as possible. Taking direct control can lead to performance gains, but use the right tool to avoid introducing bugs.

So the final result is, no matter what the user passes in or the developer passes in, we are now guarded against slow renders because we don't need to rerender when we're just changing the width of this column. So we've got two renders here instead of 254, which I think is a pretty big win. But some takeaways as I finish here. So React is fast. You don't have to prematurely optimize everything. So do wait until you have a performance issue before you start adding this complexity into your app. As you saw, memo is likely good enough, but with Agigrid we wanted to push it to the limit. We wanted to ensure that no matter how much data users put into our grid, we wanted to make sure the grid still performed because after all, that's why people are choosing to use Agigrid. So we needed to make it as fast as we could. And taking direct control, it can lead to these performance gains, but make sure you use the right tool as we looked at the different approaches to use the reference so that you don't end up introducing new bugs into your code. Thank you very much for listening. I hope that's helpful.

9. License Spaces and Custom Cell Width

Short description:

Our Agigrid license has spaces in it, preventing us from adding it in the .env file. This applies to React in general. If you're running into a performance issue, consider controlling the changes yourself using browser APIs. If a custom cell needs internal recalculations based on width, you can use browser APIs. The width should not be passed down as a prop to avoid issues.

So, okay, let's start with this one. Some tech support, please. Our Agigrid license has spaces in it, something like my company. This prevents us from adding it in the .env file. We would like to hide it from Copilot. Okay, yeah. As in, you've got a license, so send a support ticket and we'll look into that for you. Nice one, on to the next.

Does this apply to React in general or only for Agigrid-specific use case, we don't use Agigrid? Yeah, as in the code that I've shown is just all React-specific. This approach can be used. So I guess the important thing will be to not take away from this talk... Well, I do want to say, yeah, Agigrid is great. But hopefully, it will also just give you that idea if I'm running into a performance issue, what are the approaches that I can take? So I guess this morning, there was about using the micro task queue. This is another approach where the key thing here is to say, well, what's changing when I'm updating my state? Is it something that you could take care of yourself with the browser APIs? And if you don't need to use what React gives us in terms of then working out what DOM elements have changed and using the virtual DOM, then that's something which you can look to control yourself.

I love that answer. Thank you so much for that. And then what happens if a custom cell needs internal recalculations based on width? Yeah. So then that logic then can be done using, again, browser APIs. I think there's ways of monitoring how wide your container is. I think it's mutation observer. There's ways of doing that. But this is a valid question because I guess what it's pointing towards is, well, what if the width was passed down as a prop? And so then if that was part of our interface to say, we give you the width, then we wouldn't be able to use this workaround. So this is where you are constrained by the code that you've got. And if the width was a property that we passed into these custom renderers, then yeah, we wouldn't be able to do this and we'd have to make sure that things were memorized correctly. But again, as the width is a prop, it would break, useMemo would. Or the memo would still render the child component. So for us, it was, well, actually, most custom cell renderers are written in a way that they are dynamic and they can resize within that so that we don't want to pass the width down and run into this issue.

John says, hi, great work with AG grid. Thanks, John. How do you compare to the TanStack table? Yeah, we love TanStack table.

10. AG Grid vs TanStack Table

Short description:

We sponsor Tano because of the work they're doing. AG grid is batteries included, taking care of all the display and configuration. TanStack table requires writing UI components yourself and provides building blocks as a headless table.

And I think you might, if you look closely, we sponsor Tano because of the work they're doing. And we see ourselves as not competitors, but as in two different approaches to solving the same problem. So like for AG grid, we like to say it's batteries included. So you just drop our component into your page and it takes control of, and takes care of it for you, displaying all the rows, displaying the headers, the cells. You're just configuring it. Whereas with TanStack table, you've got to write all the UI components yourself. You've got to write your cells, your headers. It gives you all the building blocks as a headless table and the functionality to say which rows will be displayed but that's up to you. So yeah, TanStack table is a lot lighter because it's doing a lot less, but AG grid is a much more drop it into application, fully featured working out the box, no real work for you to do, especially as it's free as well, well free tier and an advanced one.

11. Book Recommendations and Persisting Column Width

Short description:

And do you have any book recommendations or courses to learn about patterns for performance? Is this a pattern you use often or is this a very specific example for this use case? Are side effects in a set callback essentially a hack? What happens if you need to persist the column width for next runs of the application or in a tabbed app?

And do you have any book recommendations or courses to learn about patterns for performance? Well. Are you building one? I'm not building one. But as I was reading, I just heard someone on Twitter yesterday who has written an advanced book. And so they, I would have to find it. I don't know their name off the top of my head. You may already know them. But yeah, there's definitely courses out there. I can't remember though. Okay. Sorry. That's fine. And here we are.

Okay. Is this a pattern you use often or is this a very specific example for this use case? I think it's about say this is a specific example for this use case. But again, it comes back to that point of spotting these patterns. So it's like if you run into this in a different situation where you might see a similar thing is happening, then you can apply this pattern again. So yeah, it might feel very specific to that use case but I think the important thing to take away is there's a pattern here that we can then apply if we run into this situation again.

And are side effects in a set callback essentially a hack? Side effects in a set ref callback. Let me think about that. We can come back to it. Yeah. I said it comes to what I mean by side effects. I guess there's anything which you are... I guess you got to be aware of the way that these callbacks are running and that they are the synchronous one, so there's some things in there which you might want to avoid. But I guess, you know, whether it's a hack... I don't know, you know, a lot of the things we do, some people will say, well, that's not the standard pattern, so that's a hack. But I think when you're pushing the limits, you sometimes do need to step outside of the standard path. So, but then that's also where, maybe don't reach for these initially, only go for it when you need it.

And what happens if you need to persist the column width for next runs of the application or in a tabbed app? Well, that's a great question. I think I know who's asking that question.

12. New Feature: Grid State Restoration

Short description:

In the next version, 31, coming out in November, a new feature will be added to restore the grid to its previous state when tabbing away and back. This feature has been requested by users and will be implemented.

So in our next version, in version 31, and which is coming out end of November, it seems like they've got some inside information. We're gonna be adding a new feature, which is like initial width, where, when you tab away from your grid or you destroy it, you can get the state of the grid. And then when you tab back, you pass that same object into the grid and it will restore the grid to the same width, you know, same column width, same order, and remembers all that state for you. And that's something which we know people have been doing. And so yeah, in 31, which is coming out end of November, that feature is gonna be implemented. Very good question, and it leaves us with something to look forward to as well.

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.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured 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.