Let’s Talk about Re-renders

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
Bookmark
Rate this content

React is a fantastic tool to implement complicated applications fast, we all know it. But are they going to be fast when implemented fast? Let’s talk about re-renders and their danger in react: how easy it is to make a mistake, why some small mistakes can have a huge downstream effect, and how to avoid and prevent them.

This is a deep-dive type of talk, that focuses on why React components re-render, what kind of performance impact it can have, and what to do about it

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

FAQ

In React, a component re-renders due to changes in state or props, when a value in a context used by the component changes, or when a parent component re-renders, causing all its child components to re-render as well.

useMemo and useCallback are hooks designed to optimize performance by memoizing values and functions. However, misusing these hooks by over-memoizing can lead to complex code and may not necessarily prevent re-renders if parent components are still updating.

Creating components within render functions is a major performance killer in React applications, as it leads to the components being recreated from scratch on each render, significantly slowing down the app.

React.memo is a higher order component for memoizing a component so that it only re-renders if its props change. This can prevent unnecessary re-renders and enhance performance, especially in cases where props remain the same between renders.

Context provides a way to pass data through the component tree without having to pass props down manually at every level. However, if the context value changes, all consuming components re-render, which can impact performance if not managed carefully.

Effective strategies include moving state down to components where they are needed, wrapping state around children, and memoizing parts of the render output that do not depend on state changes.

An unnecessary re-render in React refers to a situation where components re-render without any actual need for updates, often leading to performance degradation, especially in large applications.

Memoizing values passed to a context provider is crucial because without memoization, any re-render of the provider will propagate re-renders to all consuming components, even if the actual value in the context has not changed.

Nadia Makarevich
Nadia Makarevich
23 min
17 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses React performance and how re-renders can affect it. It highlights common mistakes and misconceptions, such as the overuse of useMemo and useCallback hooks. The importance of React.memo in preventing unnecessary child component re-renders is emphasized. Creating components in render functions is identified as a major performance killer, and the benefits of moving state down and wrapping state around children are explained. The Talk also covers optimizing component rendering through memoization and provides a recap of the key points.
Available in Español: Hablemos de Re-renderizados

1. Introduction to React Performance and Re-renders

Short description:

Hi everyone. My name is Nadia. I am a front-end architect, coder, and writer. I have worked in Atlassian and now I am a founding engineer in a startup called PIN. Today, I want to share my knowledge about React performance and how re-renders affect it. A re-render is when a component updates its data. There are three ways to trigger a re-render: state or props change, context value change, and parent component re-render. Unnecessary re-renders can slow down the app and should be avoided.

Hi everyone. My name is Nadia. So, first a little bit of introduction. I am a front-end architect. I am a coder. I am a writer. I used to work in Atlassian for a few years. So I worked on Jira front-end, and now I am a founding engineer in a small startup that is called PIN in Australia.

So, the topic of React performance and especially how re-renders affect React performance is something like a passion of mine. I find it fascinating that just one tiny change in the right place can either completely destroy or vastly improve performance of a huge application. So, all the knowledge about this topic is what I want to share with you today.

But first, what exactly is a re-render and why do we want to talk about re-renders in the context of performance. Generally speaking, we have two major stages of a React lifecycle that we need to care about. The first one is initial render when an app first mounted and appears on the screen, and then re-render. A re-render is second and all of them, all the consecutive renders of an app that is already on the screen. And from a code perspective, we have at least three ways to trigger re-render of a component. First is the most known one is when a state or props change, this is when a component will be re-rendered. Second one if we use a context, then when a value changes, every component that uses this value will also re-render. And the third and most under appreciated one is when a parent component re-renders or if we look from the top, that means that when a component re-renders itself, it will re-render every single child that it has. If we want to visualize the last one, because it's the most important one, it will look something like this. We have a tree of components, the top one will re-render, and then this re-render will trigger a re-render of all the children there, and then all the children underneath, so it will be a whole chain of re-renders that triggers from the top.

And generally speaking, a re-render itself is not something that we would want to fight with, because it's an essential part of a React lifecycle, it's when React updates all the data that has changed. What we want to avoid at all cost is unnecessary re-renders. And by unnecessary re-render, I mean something like this. So imagine we have an input component somewhere at the bottom, we type something there, and then this component naturally will re-render itself. That is good, and that is expected. What we don't want is when we type in this tiny input component, to re-render the entire app. This, depending on the size of the app, can be extremely slow. And in today's world, users will expect all the interactions on the page to be really, really fast. So unnecessary re-renders is a performance killer.

2. React Performance Mistakes and Useless Hooks

Short description:

And to demonstrate how bad performance can be, I implemented an app that renders a list of components. Mistakes in the code made the app unbearably slow. One common mistake is the myth of useMemo and useCallback, which leads to an app full of useMemo and useCallback hooks. However, memoizing everything can make the app incomprehensible and not debuggable. Additionally, wrapping onClick in useCallback may be useless because child components can still re-render when the parent component re-renders.

And to demonstrate to you how bad those can be, I even implemented a little bit of an app. So this is an app that renders a list of components, and has a little bit of interactivity. So take a look. On the right, Performance tab, I click everywhere, and everything is instantaneous. On the left, exactly the same app, but I made a couple mistakes there, and look how unbearably slow all of this is. Just a few tiny mistakes in the right places, and I just destroyed this app. And it's just a list of components.

So common mistakes that lead to performance like that, and also useful performance tips and tricks to avoid re-renders of the entire app, is what I want to share with you today. Let's start with mistakes. The very first one is one of my favorite, is what I call the myth of useMemo and useCallback. So as probably most of you know, React uses referential equality when it compares props or dependencies in all the various hooks. And referential equality is basically this. We have two arrays or two objects. If we want to compare them, if we do it like this, the result will be false, because we're comparing them by the reference, not by the actual value.

And from React's perspective, it sounds like this. We have a component, it renders a child component. I pass a value to this child component that is an array. If I do it like this, during a rerender, this value will become a completely different value. So if React compares those props, React will think that value of the prop has changed. And if I write a memo and use callback hooks, hooks that allow you to memoize this value, and basically to preserve reference to this value between rerenders. So if I extract this array into useMemo hook, then when a rerender happens, React will think that value in a child component will be exactly the same. And the fact that one of the most important reasons why a component rerenders is a state or prop change, in combination with how those hooks work, lead to the widespread belief that if we memoize all the props on a component, that will prevent this component from re-rendering. And this results in something that I call a useMemo or useCallback hook hell, because memoizing absolutely everything leads to your app becoming, having useMemo, you wrap in useCallback, and then another useCallback, it's just useMemo and useCallbacks everywhere, and the app becomes incomprehensible and completely not readable and not debuggable. So I think those become really horrible.

But the worst part of all of this is that it's actually sometimes, it's actually useless, because we're forgetting one key component in all of this construction. So if we take a look, for example, at this code, we see a component, it has a child component and then onClick, Prop, and we want to prevent child component from re-rendering by wrapping onClick in a useCallback hook. But what exactly can trigger child components to re-render? We prevented Prop from changes. The only thing that is left when a parent component re-renders. So we will trigger a state, for example, a child component will re-render, and React will not actually check whether Prop has changed or not at this stage, because React's natural way of dealing with components is components re-render, and then re-render every single child. Wrapping onClick here in useCallback is just completely useless, we are doing nothing here.

3. Preventing Child Component Re-renders

Short description:

The only way to prevent the child component from re-rendering when the parent component re-renders is actually wrapped in React.memo. And only in this scenario, when a parent component re-renders, the re-render of this child will be stopped. In this case, the component react will stop, and then we will start comparing all the Props with the previous value, and if all of them are the same, then nothing will be re-rendered.

The only way to prevent the child component from re-rendering when the parent component re-renders is actually wrapped in React.memo. And only in this scenario, when a parent component re-renders, the re-render of this child will be stopped. In this case, the component react will stop, and then we will start comparing all the Props with the previous value, and if all of them are the same, then nothing will be re-rendered. So, from code perspective, this, when we have just the child component, and then a use callback that is, wraps a Prop, it's useless. It does nothing. It just consumes a little bit of computational power. It should be something like this, or just remember use callback. wrapped in React.memo, and then, and only then, a use callback will be actually useful.

4. Creating Components in Render Functions

Short description:

Creating components in render functions is a major performance killer in React applications. When components are created inside a parent component, React recreates them from scratch during every rerender of the parent component. This not only slows down the app, but also causes visible flashes on the screen and introduces bugs with focus. The solution is to create item components outside of big components and avoid creating components in line.

Second mistake, and this one is the major performance killer in React applications. Creating components in render functions. Again remember the app. The app is just a list. Apps, it accepts countries as a prop, and then we iterate over those countries and render something. In real life, obviously we would want this button to have some styles, to have some functionality, so in real life I would want to extract this button and make it a component. And what people often do is they extract it as a component and create it inside this exact component, it creates inside a parent component. Usually the reason for this is it's just much easier to pass additional data to it that is derived from state, but still. But when we do something like this, during every single rerender of the big list component, React will recreate the item component completely from scratch. React will just unmount everything that is already rendered and then remount all those list components. This is not only going to be really, really slow, mounting is twice as slow as just a render. It is also going to be visible on the screen, because what will happen is a list component with items, lists the renders. React will think that all the item created inside the list is a new component now, so it will destroy all those items, remove them from the screen, and then recreate them back. Sometimes we will see a visible flash on the screen. And also numerous bugs with focus. So the way to fix this, of course, is just never do something like this, and just create item components outside of big components, never create components in line.

5. Context Provider and Moving State Down

Short description:

The third mistake that causes spontaneous and unnoticeable error renders is the context provider. When a context value changes, React needs to rerender every component using that value. To fix this, always use memo on the context value. Another trick to prevent unnecessary rerenders is the pattern called Moving State Down. By extracting the state into a separate component, only the necessary children will rerender when the state is updated.

Third mistake that is probably the most important source for all those spontaneous and unnoticeable error renders across the entire app is context provider. So context is a really useful tool when we need to pass some data and avoid props trilling. So with context, we can do this. We can just escape all the components in between and pass data from the top component to the bottom component. Without context, what we would have to do is pass data through every single component in between the top one and the bottom one, which will cause all the middle components just explode with props and unnecessary data and just turns into a nightmare of refactoring in six months.

But there is one caveat with context. When a context value changes, React would also need to update everything that is using the context value. And that means that React needs to rerender every single component that uses context value. And from a coding perspective, it looks something like this. We have a component, we have context provider, and we need to pass value there. What will happen if this component rerenders by some reason? Remember, differential equality. We have an object that we pass to context provider. Component rerenders. React thinks that object is a different object. It changes, it thinks that a value changes, and then it will unnecessarily rerender every single component that uses this context. And the way to fix it would be just to use memo on this value always. I would say this is one of the very cases of premature optimization that you actually want, because debugging rerenders that are happening because of the changes in context is just a nightmare to do.

Okay. So let's now stop depressing ourselves over the mistakes and talk a little bit about the actual tricks. One of the most important ones in your arsenal against unnecessary rerenders is the pattern that is called Moving State Down. So if we look at the code, we have a component, it renders a lot of stuff, it's very heavy, and at some point we implemented a button there, click on the button, opens a model dialogue. Super simple functionality this whole implementation. So what will happen in this big component from a rerender's perspective? We click on a button, we update state, and then this entire thing rerenders, because when state is updated, every single child in the component will rerender. And of course, something like this is going to be really, really slow. If it's a really big app, click on a button and then opening a model dialogue could cause a visible delay, because React needs to re-render everything first before actually opening the dialogue. Our users will be very disappointed. The way to fix it is what is called moving state down. This state is actually quite separated from the actual functionality of this big app, so what we can do is just extract all of this and wrap it in a component itself. And then use it back in this big component. So now from ReRender's perspective what will happen? We click on a button, state is updated, children are re-rendered, but in this case children are just a button and a model dialogue.

6. Optimizing Component Rendering

Short description:

The big component will just sit there and do nothing. That is exactly what we want. And opening of the dialogue will be now as fast as possible. Wrapping state around children is another pattern that is underappreciated and least known. It's similar to moving state down. When listening for a scroll event, we can extract the state outside the wrapping div and create a new component. This way, the child component doesn't re-render, making the app faster. Another technique is memorizing part of the render stream, where a big chunk of the stream that is not dependent on the state can be memoized.

The big component will just sit there and do nothing. That is exactly what we want. And opening of the dialogue will be now as fast as possible. Second pattern and this one probably is the most underappreciated pattern from the series and also the least known one. That's wrapping state around children. It's a little bit similar to moving state down. So again, we have a component. In this case we want to for example listen for a scroll event. So what we will do here, from a re-render perspective again, user scrolls. We are triggering state updates. Update is triggered. That triggers a re-render of entire big component. And again, everything re-renders. But in this case, we cannot just move the state outside because this div is actually wrapping the entire component. But what we can do is we still can extract it outside, create a new component out of all of this, and then pass everything that was between those divs as children.

What will happen here from a re-render perspective and how to use it? So now, we scroll. We trigger state update. Update is triggered. It triggers re-renders. The scroll component re-renders itself. But everything that is inside here belongs to the parent. The child component doesn't know about all of this. From the scroll component perspective, all of this is just a prop. All of this will not re-render. Now this app becomes as fast as possible again, without any memorizations, without anything.

And last but not least, memorizing part of the render stream. So when you have a big component, you use some state here and there. But you cannot either move a state down or just wrap it around children, because it's just scattered across the app. But also, if you want to improve performance of this app a little bit, and you have a big chunk of the stream that is not dependent on the state, what you can do is just memoize this entire stream. In this case, again, update is triggered, re-render is triggered, no dependency in this memo, so useMemo will just return exactly the same value that was before.

QnA

React Performance Recap and Q&A

Short description:

It will not update anything. Always memoize values in the context provider. Wrapping state down and wrapping state around children are the most important tools in your fight against unnecessary re-renders. If both of those are not possible for some reason, you can also memoize expensive parts of render chain. If you want to read a little bit more about all of this, or play around with the bad app and the good app, here are the links. Feel free to do it. Let's jump into some questions. What will happen if we pass the object to a child component, which is exported with React memo? If a child component is wrapped in React memo, and we're just rendering it, then we need to memoize this object. Otherwise, if object is not memoized, the component that is wrapped in React memo will still be rendered.

It will not update anything. And performance of this big app still is going to be much better than without this.

That was a lot of information, I hope you found some of it at least useful. A little bit of a recap for everyone. If you're not using useMemo and useCallbacks the correct way, which is trapping component in react.memo and memoizing every single one of them, they become useless. You can just remove them. Creating components inside render functions is the biggest performance killer ever. Never do it. It just should be your mantra. Always memoize values in the context provider. That will prevent React context consumers from re-rendering unnecessarily. Wrapping state down and wrapping state around children are the most important tools in your fight against unnecessary re-renders. If both of those are not possible for some reason, you can also memoize expensive parts of render chain.

If you want to read a little bit more about all of this, or play around with the bad app and the good app, here are the links. Feel free to do it. I write a lot about all of those stuff and all different various patterns in my blog. Feel free to connect with me on Twitter or LinkedIn. Always happy to chat and answer questions. Thank you! Thank you so much Nadia, that was a really amazing talk. I had to take a picture of that slide at the end, because there's some of those takeaways that I want to make sure I am using myself.

Let's jump into some questions. If you are in the audience and maybe you're quickly going off to another talk, that's totally fine. Let's just keep the noise down so that we can hear all these questions, even in the back. All right, let's just jump straight into it. What will happen if we pass the object to a child component, which is exported with React memo? I'm not sure if I've read that correctly. If a child component is wrapped in React memo, I assume, and we're just rendering it, then we need to memoize this object. Otherwise, if object is not memoized, the component that is wrapped in React memo will still be rendered. Because React thinks that props are different, so it will trigger a render. That makes sense. That makes sense.

React memo and Rendering Children

Short description:

React memo with the child is not the default behavior for rendering children. Memoizing everything can make the app slightly slower, increasing the initial render. It may or may not save you from re-renders.

And one thing, this is also something that popped into my head. Why is React memo with the child not just the default behavior for rendering children? Because it makes so much sense to use it that way. It makes so much sense. But as far as I know, React team, I'm not part of it, so I just use the internet. They experimented with doing exactly that during build. But just memoizing everything also has its costs. So if you just memoize everything, it might make your app slightly slower. Because again, if everything is wrapped in React memo, but you're not wrapping everything in the used memo and used callback, those are useless, but you're still doing stuff during that. So it can increase your initial render. It may or may not save you from re-renders, but will definitely increase your initial render. Makes sense 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.