Using useEffect Effectively

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

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.

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

FAQ

In React 18, effects executing twice in strict mode indicate potential misuse of useEffect, suggesting that certain effects should not be used within it.

Stately.ai primarily focuses on state management, logic, and effects in software development.

Dependency arrays in useEffect are crucial for optimizing performance by preventing effects from running on every render, instead running them only when specific values change.

Activity Effects are ongoing processes watched within the component lifecycle, suited for synchronization in useEffect. Action Effects are fire-and-forget actions, typically handled in event handlers or state transitions, not in useEffect.

Instead of using useEffect for data fetching, developers should utilize frameworks or libraries like React Query or Remix, which offer more efficient methods for managing data fetching and state.

David Corschied recommends using the stately.ai editor for visualizing state machines, which is a free tool.

Common issues include infinite loops, race conditions, and challenges with cleanup functions. React 18 also introduced double execution of effects on mounts, causing additional complexity.

David Khourshid
David Khourshid
30 min
21 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
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.
Available in Español: Uso efectivo de useEffect

1. Introduction to use effect

Short description:

Hello, everyone! My name is David Corschied and I work at stately.ai. Today, we're going to talk about our favorite hook, use effect, and how it simplifies things compared to class components. Let's dive in!

All right, hello, everyone. My name is David Corschied, and my slides will be showing up shortly. I'm sure... Oh, yeah, there it is. David Corschied. I'm at David K. Piano pretty much everywhere. I'm very excited to be in London. Again, I work at stately.ai, where we think a lot about state, logic, and effects, but enough about me. If I keep going, then this talk is going to last longer than your next prime minister, so let's get on with it.

Okay. So, of course, I work at stately, and one of our engineers, Matice, you might have seen him. He's in your NPM, your node modules, I guarantee it. He's one of the most talented developers I know. Yesterday he created a PR where he asked, am I 100% confident in this fix? Hell no, it's based on use effect. So, we're going to be talking about that today, our favorite hook, use effect. But let's start from the beginning. Who remembers class components? Right? So, yeah, some people really want them back. So do I.

All right. So, in this example, I remember that when react came out, I was very excited for it. I'm like, wow, this is going to change everything, and react did change everything on every single render. So, over here, we're doing what most components do, or what most React developers do, which is fetch data and show it on the screen. Admit it. That's 90% of your job. But we had a nice, convenient, little life cycle hook component to do that in. But now things are different. We have use effect. So, I remember I learned about use effect in 2018, and I was very excited to use it because I'm like, wow, this makes things a lot simpler. So instead of making these big, bulky classes, we have these hooks that we can put things in.

Read also

2. Fetching Data with Use Effect

Short description:

I wanted to fetch data using new JS syntax in 2018. However, when I put it in use effect, React yelled at me. It didn't know what to do with the async await syntax, so I had to use .then instead. Even though I thought I had it figured out, the next day my AWS failed due to an infinite loop caused by continuous fetching. I realized I needed to read the documentation and discovered the tip about using a dependency array. By adding an empty array, I could optimize performance and avoid infinite loops.

I wanted to fetch data. It was 2018, so I wanted to use new JS syntax. And it was in effect. So, I put it in use effect.

Tried this, React yelled at me. It said, listen, this async await stuff, it's fancy, but you cannot use it like that. You have to, you know, we, it doesn't infer that, hey, I don't know what to do with this because it promises that you return from use effect. So, we had to do things like it was 2015 and use.then.

So, I fetched some data, then I set the data. I'm like, this is simple. I just put it in the use effect. I get my data. I'm good to go. Right? Wrong. Guess what happened to my AWS fail the next day? Yeah. So, this, by the way, it will keep fetching and fetching and fetching. And it really won't, React won't tell you that, hey, this is going to occur as an infinite loop.

All right. So, at this point, I'm like, okay, maybe I should read the documentation a little bit. So, I scrolled all the way down. And so, there was a tip. It's just a tip. You know, this very crucial bit of information is a tip in the current React docs. Docs optimizing performance by skipping effects. And so, I learned that you're supposed to use this little dependency array. And since this didn't really have any dependencies, you just put it empty like that. If you look at it sideways, it sort of looks like an agonized React developer screaming into the void.

So... Yeah. All right.

3. Handling Race Condition and Cleanup in useEffect

Short description:

I learned what the dependency array is for. However, I discovered a race condition when fetching data with different IDs. To handle this, we need to implement a cancellation mechanism and ensure proper cleanup. Some developers copy-paste the solution, while others create custom hooks. This approach worked well initially.

So, I learned my lesson. I learned what the dependency array is for. And so, everything was good. Right? Well, now I discover that we have something called a race condition. Because when I fetch something with an ID, and then I decide, you know what? I'm gonna fetch something with a different ID, if that ID is cast, then that promise is gonna resolve first, while the first one is still going, because we didn't cancel it. So, now we have to do the dance. This is a dance that so many of you have done before, and that's having this is canceled false flag, or React calls it ignored in the official documentation, and then you have to make sure that we haven't canceled this promise, that you have to have a cleanup in there, and you have to do all this. So some of you just copy-paste this, some of you put this in a use promise or a use async custom hook, which is totally fine. And this worked well for a while.

4. React 18 Effects and Correct Use

Short description:

Until React 18, effects executed twice on mounts. React simulates an unmount and remount. Many signs indicate incorrect use of useEffect: React 18's double exec in strict mode and development, long dependency arrays, complex conditionals, missing cleanup functions, conditional cleanup functions, and ad hoc state calls. React recommends using effects with a capital E for side effects caused by rendering. There are two types of effects: Activity Effects and Action Effects.

Until React 18. Where effects execute twice on mounts. So when I first discovered this I didn't know it was a React 18 thing. Am I doing something wrong in my code? What did I do? Did someone change something? Was it the Torys? I have no idea.

So what's actually happening over here? So I looked it up and saw, OK, we mount an effect, and then React is actually simulating an unmount, and then React is remounting it again. wondering why the heck was it doing that. And so I did a lot of digging around. I was looking at the second official React docs, which is random Twitter threads by the core maintainers, and I realized that, you know, useEffect, it felt like a defective thing. I'm like, we really, really shouldn't be using it, you know, and the more we use it, the more we feel like this. Right? So, you know, of course I calmed down a bit, researched a bit more. Learned about how useEffect works. And so the answer might surprise you. It doesn't. It doesn't for many effects. Okay? It actually does work. But there's many tell tale signs where you could see, okay, maybe I shouldn't be using a useEffect. First of all, React 18's double exec, that thing that it does only in strict mode and only in development environments. This is an eviction notice, basically. When this happens and part of your app breaks, it's basically React telling you, you shouldn't be using this effect inside of useEffect. Also, there's other symptoms like long dependency arrays. When you have complex conditionals inside of your effects, if you're missing cleanup functions or if those cleanup functions themselves are conditional, or you might have ad hoc state calls littered throughout the place. These are all pretty telltale signs or side effects that might indicate you're probably using useEffect wrong.

So, okay. Which effects then should we be using in useEffect? In the new React beta documentation which I'll give a link to later, they say that there's really sort of two types of effects. The effects that, with a capital E, those effects let you specify side effects that are caused by rendering rather than by a particular event. So we're going to get into the difference right now. So React refers to two types of effects, effects with a capital E and events. So effects that, you know, are supposed to happen in event handlers, but I think this is a little confusing. So for the duration of this talk I'm going to be calling them activity actions, or sorry, Activity Effects, and Action Effects. And so Activity Effects are something that is, it's an ongoing process.

5. Understanding Use Effects and Action Effects

Short description:

Use Effects, the hook specifically, is for synchronization with Activity Effects. Action effects go in event handlers, or like sort of. Move the effect closer to the event handler to avoid re-rendering and tie it to the actual event that caused the effect. Action effects happen outside of rendering. Here's an example with multiple issues: using isFocused prop to focus a component, which introduces indirection and the possibility of an impossible state. Refactoring with forward ref or imperative handle can solve these issues.

It's something you don't forget about while you're in the lifecycle of your component, you're intently watching it. So this might be a subscription or watching a live stream of A Head of Lettuce or something like that. An Action Effect is something where you explicitly execute it, it's fire and forget, you don't care what the end result of that is, like Brexit. So what is Use Effects for? Use Effects, the hook specifically, is for synchronization with Activity Effects. Not with Action Effects, but with Activity Effects. So one example of this is, for example, a listener, a resize, a mouse move, something like that, where you create a Handler, you add that Handler, and you make sure to use that cleanup function to say, I don't want to listen for this anymore. And because Activities are ongoing things, it's sort of like watching television where it doesn't matter how often you turn on and off the TV, the channel is still going to keep going. You're not imposing any side effects by turning it on and off, it's not like you turn off the TV and the BBC is like, all right, let's cut it, this person stopped watching, it doesn't work that way. So where do action effects go then? We know that we can't really have side effects in Render, and you actually sort of can, but we won't get into that here. We know that putting it in useEffect is awkward, because David said so, but what about outside the component? That's an idea. So where do action effects go? In reality, they go in event handlers, or like sort of. In this example we have an onSubmit, and we are submitting the data directly inside that onSubmit, and I'm gonna show you the alternative later. But the real mental model is you want to put your fire and forget, your action effects as close as possible to the event that would have caused the effect. And so here's how this helps with React 18. We know that when something changes, our component is going to re-render, and if we tie that effect to rendering, then React, remember, it has the ability to just keep re-rendering that component, and because you tied it to rendering, it's going to just keep executing those effects, which we don't really want. But move the effect closer to the event handler, and you avoid that problem completely, because you're not tying it to render, you're tying it to the actual event that caused that effect to happen. So action effects happen outside of rendering. All right.

So here's an example which actually goes through quite a few issues. And I've seen this before. I've even done this. There's an isFocused prop. And so this isFocused prop makes sure that when we focus a component, so isFocus equals or listening for that state change and so when that state changes, we are going to execute that use effect which is then going to focus the event. So there's a lot of indirection going on here just in order to, you know, get that component to focus and also there's a possibility of an impossible state like what if you have multiple isFocused is true. In short, if isFocused shouldn't really be a prop. But let's see how we can refactor this, at least outside of use effect. So instead, we could use a forward ref and we could just consume that in the components where we have this input ref equals use ref. And even though this is a fancy input, we could use forward ref to grab that. Or if you really want to, use imperative handle. I didn't put in the slides because I don't want people screenshotting it and being like this guy's recommending use imperative handle.

6. Executing Effects in Event Handlers

Short description:

Check out the declarative approach where we're saying when something happens, causes the state to change, and depending on which parts change, this effect should be executed, but only if some condition is true.

That's too spicy for this talk. But anyway, check it out. We are doing the side effect directly inside of the event handler. And so the result is we have a very clean component, we have no use effects in sight, and this is just extremely simple. So when we think about this, though, like executing an effect directly inside of use effect, it feels... Or, sorry, executing an effect directly inside the event handler, it feels imperative. It feels like when something happens, execute this effect, you know, it feels a little weird, feels a little side-effect-y, and not really functional, right? But check out the declarative approach where we're saying when something happens, causes the state to change, and depending on which parts change, this effect should be executed, but only if some condition is true. And React may execute it again for some future reason, but only in strict mode, which you shouldn't disable, for some future reason. And I've tried to hear the explanation for this, I think it's something with offscreen mode or some, like, every single time I hear it, it's just, I lose the reason why, but just don't do it.

7. Exploring Misuses of Use Effect

Short description:

Now let's dive into the Beta React docs. We'll explore the sections where people commonly misuse Use Effect. One such case is transforming data, where Use Memo is a better option. Start without Use Memo and only use it if performance issues arise. Additionally, avoid using set state in Use Effect to prevent infinite loops. Another misuse is using Use Effect for communicating with parents, which highlights indirection. Instead, utilize props like onOpen and onClose.

Okay, so. Now we're gonna get into the Beta React docs. Just checking the time. Ooh, not much time. Okay, so Beta React docs, I'm so thankful that these docs exist, by the way. So, by the way, if you go to reactjs.org, there's a nice header over here, and you can go directly to the Beta React docs, which we had this three years ago, but it's great that we have it now.

Okay, and there's a section here called you might not need an effect. So we're going to go over a few of the sections. Not all of them, because then this would be a much longer talk. But yeah, let's go through them one by one, especially the ones that are most common to what I see people using Use Effect for, where they shouldn't.

So the first one, you don't need Use Effect for transforming data. So here's an example over here, where we're calculating the total of a number of items right in Use Effect, which makes sense, right? Whenever the items change, we need to set the total. Guess what? That's a very imperative way of thinking. Instead, what we could do is just put it inside Use Memo. Because total is a derived value, and Use Memo is very good for derived values. But guess what? You might not even need Use Memo. Honestly, start without it. And only if you start to notice performance problems should you start to use Use Memo. I'm saying use a lot. But yeah, much simpler. Get rid of the Use Effect.

And of course, we know that putting set state in Use Effect, it could cause a whole bunch anyway, leading people to think, I will never understand why the default behavior of Use Effect is an infinite loop. I've run into this before and the React docs warn you. You shouldn't do this. This is why. It's because this is going to trigger a re-render, which is going to trigger the effect again, et cetera, et cetera. You don't need Use Effect for communicating with parents. This is an interesting one that really highlights the indirection that's going on. We have onOpen and onClose as props. Whenever we open something here, like, let's say that this is a product view, we change the state, and then depending on whether it's open or closed, we're going to call those props.

8. Optimizing Use Effect and Fetching Data

Short description:

We're doing that by putting isOpen in a dependency, which is going to trigger the Use Effect. Instead of Use Effect, put it directly in the event handler. You don't need Use Effect for subscribing to external stores. Use the useSyncExternalStore hook. You don't need use effect for fetching data. Just use the framework and React query.

We're doing that by putting isOpen in a dependency, which is going to trigger the Use Effect. You can see here, we're clicking, state's changing, then we have an effect. Lots of indirection. So, instead, get rid of the Use Effect, put it directly in the event handler, and now it becomes much more straightforward and easier to understand. So, now instead, we are just calculating the next state, because we know the next state of that is open, and depending on that state, directly call onOpen and onClose. And then you could even put it inside of a hook.

So, all right. You don't need Use Effect for subscribing to external stores. This one is a really interesting one, because it sort of goes counter to what I was just talking about. It's like Use Effect is really good for subscriptions, right? Well, over here I'm subscribing to a store API, and all I'm doing is getting some specific value, like whether I'm connected or not to the store API, and then I have an unsubscribe here. So, we're still a little bit of an indirection here because we are setting a local state variable. Guess what? You could actually get rid of this and use the useSyncExternalStore hook, which has three parts. A subscribe part, where you tell it, here's how to subscribe, here's a function you need to call to subscribe, the getSnapshot part, which is, this is the value that I want to get, and here's how to read it from that store, and a server snapshot where it's just good for SSR. So, you put all those three things together, it's going to automatically subscribe and get you the value you need, no use date, no use effect. It's a really brilliant hook. So, I do recommend that you at least try it out. They say it's only for library authors, but they also said, like, do not use, or you will be fired, it's only for React maintainers, but we're seeing libraries use it for whatever reason, like Preact Signal and stuff like that. So, go ahead and use it. Not that one. But use sync external store.

All right. This one is a big one. You don't need use effect for fetching data. Like we talked about in the beginning, that was one of the big reasons that we used use effect. So, instead of all of this that we were doing before, just use the framework. Whatever you're using, you're likely using a framework. Remix has a really nice loader over here. get server side props. This is going to be available to you directly in the component. And then there's a library that hopefully most of you are using for fetching data, which is React query.

9. Fetching Data with Use Query

Short description:

Instead of use effects, use query or SWR to start fetching data as soon as possible. The cache feature prevents unnecessary re-fetching and avoids waterfalls. Remember to fetch data early and cache it.

But notice over here I'm doing something different. I'm doing query clients.prefetch query. Because the idea is that we want to start fetching as soon as possible, which is a subject of a whole other talk. So instead of use effects, really use query. Next.js says use SWR. Or just use. This is going to happen in the future. If you're not familiar with the use hook, it basically acts the same. This is going to be the new upcoming way of doing suspense, I think. It's an RFC. React might kill it. They like doing the whole Google thing where they kill stuff. Just kidding. They've shipped a lot of really great stuff. But the important thing is this cache over here. This cache means that whenever we try to read this, we are not going to keep re-fetching and re-fetching. I guarantee you, you're going to see React tutorials where they forget about this whole cache part or they start fetching in here. You're going to get waterfalls again, so just make sure, fetch as early as possible and cache.

10. Problems with Fetching and Use Effect

Short description:

Dan discusses problems with fetching and use effect, including race conditions, loading spinners, and chasing waterfalls. Avoid using use effect for initializing global singletons. Instead, move the effect outside the component. You don't need use effects for handling user events. Move the logic inside the event handler and abstract it to a hook.

And Dan talks about a lot of problems with fetching and use effect. First of all, the race conditions that we talked about, there's no instant back button. You're going to see loading spinners everywhere when you try to go back because components are going to try to load again. No initial HTML content, so you're going to have even more loading spinners, and you're chasing waterfalls because the parent's going to load and when that's unloading, the child's going to load. When that's unloading, et cetera, et cetera. And so you want to avoid those things.

Okay. So another thing, you don't need use effect for initializing global singletons. So here's what I mean. Let's say we've done this a lot, where we execute some sort of effect right when our app starts. And so we're like, use effect is the right place for effects. So we're calling this store API.authenticate, but we know that in React 18, this is going to run twice. So instead, we use a ref and we say, hey, did this already run? Maybe not. But this is honestly sort of a red flag. So I recommend you not do it. So instead of using a ref, we could just stick that outside. But guess what? Why don't we just stick the entire thing outside? Look how simple that is. A lot of you might be internally screaming. This is something that Dan recommended on Twitter, so I feel okay putting this on the screen. But if you're using Next, you can check if type of window is undefined or not and call it conditionally like that and if you're going to scream about testing, just wrap it in a function, you know? You could even inject that story API, do whatever you want to do. You know, just do it outside of the component.

And then the biggest one for me, you don't need use effects for handling user events. And so this goes to activity effects versus action effects. So now we're talking about action effects. So in this one, we are submitting a form and we're setting all of these variables, so set is loading is true. Set the form data to the event. And so that's going to be indirect and trigger a change. This is wrong. What you should do is move it inside of the event handler. So move it inside of submit and then you know, you might need to add a whole bunch of extra logic, but because you're not using use effect and you're isolating it to that event handler, you could easily abstract that to a hook.

11. Handling Effects with State Machines

Short description:

My favorite type of hook is use reducer. It's a library I maintain. It works similarly to Redux. Let's consider a bigger example where we have a cool video. We use three use effects to handle various actions, such as playing, ending, and closing the video. By thinking in terms of declarative effects and using a State Machine, we can execute effects directly on transitions.

My favorite type of hook looks like this where you have a state and a send. And all you have to do in your components is send events. This is use reducer. This is X-Day. It's a library I maintain. This is Redux. Zushan sort of works the same way.

Yeah, but so here is a bigger example. I wanted to just make this cool video where it's a thumbnail, but when you click it, it goes full screen and then there's many ways to close it. There's three use effects that are handling this. So the first one we are checking is playing. And so if we are playing, the VideoRef is, you know, we have to play it or we have to pause it if it's not. The second one, we are listening for the video to end. And if it's not ending, then we have to set is playing to false. And remember, this is going to trigger some indirection. It's going to trigger the state's change, and then the state is going to trigger the previous effect. And the same thing over here. When we press the escape key, again, we are setting is playing to false, and now we have a little bit of cleanup too.

So the way I like to think about these instead in terms of declarative effects is by using a State Machine. And no, I'm not going to talk about XSEED in this talk, but you can talk to me afterwards about it. So with State Machines, you declare the effects that are going to execute directly on the transition. And I think this is brilliantly simple. So for example, when we're in Mini and we transition to Full, we're doing it on a toggle and we play the video. Same thing when we're going from Full to Mini. We go from Toggle, and we're pausing the video, and then we do the transition. So if you haven't used Xstate, just imagine this as Redux or your standard reducer. Imagine if you could execute effects directly inside of your reducer. It's basically the same idea.

12. Effects and Tools for Real-World Use

Short description:

Imagine executing effects directly inside your reducer. State machines are purpose-built for declaratively expressing effects. Action effects go in state transitions executed around the same time as event handlers. Use effect is for synchronization, activity effects go in use effects, action effects go in event handlers, render as you fetch, and state transitions trigger effects. Thank you all! You can ask questions on Sli.do. I use slides.com for my beautiful presentations. Let's talk about tools for real-world use. Watch my talks, read the beta React docs, and avoid the old docs. They provide resources and examples of when not to use use effect.

Imagine if you could execute effects directly inside of your reducer. It's basically the same idea. I really like this because it really gives you a visual way and a declarative way of thinking about all of your effects without having to just tangle your mind and think, okay, when is this effect going to execute? I have absolutely no idea. So yeah, this is just my way of telling you to start looking into, I guess, state machines because state machines are purpose built for declaratively expressing all of these types of effects.

So in summary, or not summary, but where do action effects go? Not really event handlers, but technically they do go in state transitions, which happen to be executed at around the same time as event handlers. Now I don't have much time, so let's wrap up with a summary. Use effect is for synchronization, activity effects go in use effects, action effects go in event handlers, you should render as you fetch, and last but not least, state transitions trigger effects.

So with that said, I want to thank you all very much. Amazing! Please, step into my office. Thank you so much, David. That was fascinating, and also very funny, which I appreciate. Remember you can ask questions on the Sli.do. The code is 2124. As per usual, the people want to know what presentation software are you using? Because it's beautiful This is slides.com because I'm too lazy to learn keynote. Also slides.com is super easy, plus you can customize it with CSS. They have that magic move thing, too. It's really nice. And present offline. That's what I use.

Oh, yes. Let's talk about effects. I love a You Might Not Need concept. Because I'm a simple gal, I don't like to overcomplicate things. But if I wanted to take all of this into, say, the real world, a team, a job, are there any tools we could use? Some linting, some notes, a blog post, any sort of resource in order to ensure we're conscious of these things? Good question. I mean, I guess you could watch my talks, but then they're gonna be like, oh, this is just David blabbing on about use effects. So I'll write a blog post about it. The official React docs, the beta docs. Honestly, stop reading the old docs, read the beta docs. Those are gonna be the resource for basically everything I talked about during this talk. And they even have a couple more examples of where you should not use a use effect.

13. Linting Rules and Fetching Alternatives

Short description:

As far as linting rules, just let React 18 make your app crash in development. What are your thoughts on the lint rule that says not to put functions in your event handlers? Don't add lint rules until they become a problem. When depending on arguments for your request, start fetching as early as possible. React rendering is not about events, but rather the user or external actions. UseReducer and Redux are state containers, not meant for fetching effects. With state machines, indicate new states and the effects to happen.

So definitely read through that. As far as linting rules, just let React 18 make your app crash in development. And be like, oh, why'd that happen? Probably a use effect. I feel like I know the answer to this, but what are your thoughts on that lint rule that's like, don't put functions in your event handlers? Don't put... How about don't add lint rules until they actually become a problem? How's that? That's great. Cheers for that.

All right, we have a few questions. All right. Fetch as you render sounds good until you depend on arguments for your request. What is the best approach then? Well, think about when those arguments happen. The user probably initiates it or it's coming from an outside source. So, for example, the user might press a button, might fill out a form, and then when they submit a form, that point where they submit a form, that's when you should be initiating the request. What a lot of React developers do is they'll submit a form, that gets set to state, or that gets passed down as a prop to a component, and then the component's like, oh, hey, I have a prop, now I can read that prop and fetch data based on that prop, but there is a lot of indirection there. So, start fetching as early as possible. You're going to learn that React rendering is not an event, or it's not the events that you should be caring about. The user actually doing stuff or some external thing doing stuff, that's what you have to focus on.

There's a lot of questions and I'm going to sort of bundle them together about all the alternatives. So isn't use-reduce good for fetching? Or, do you think we're going to use Redux again? Or when would you use use-effect without a dependency array? What about use-event? All the uses. So, use-event's dead. You know, React likes killing stuff. So... Yeah. What were the other alternatives? Things like, all right, use-reducer, Redux, etc. These are state containers. They're not really ways that you would fetch effects. But like I mentioned, you know, with state machines, you should be thinking about, when your state changes, you should have some sort of way of indicating... This is a new state. And these are the effects that are supposed to happen. A lot of times, when we think about it, we're like, here's a new state. And then we have some middleware that runs where it's like, okay, maybe I'll fetch.

14. Discussion and Conclusion

Short description:

But I think that both of those should go together. What tool did you use to visualize the state machine in your slide? It is a stately.ai editor. Did you ever think about contributing to the React docs? I did contribute once. Their actual source code might as well be closed source. Great talk. Are your slides going to be posted online? Follow David on Twitter at David K. Piano. Thank you, David.

But I think that both of those should go together. Thank you, David. What tool did you use to visualize the state machine in your slide? Good question. Not a planted question, I promise. It is a stately.ai editor. It's free to use, play around with it. It's really pretty. Yeah.

Okay. One more. Oh, actually, maybe two more. Did you ever think about contributing to the React docs? Yes. So, I did contribute to the React docs once, because they had used timeout-ms. That was for a very, very old suspense API. But I was, like, wait a minute, it just says use timeouts in the docs. I could add that little ms to the side. That was my first React contribution, because their actual source code might as well be closed source. There's, like, bit shifting and all of these weird fiber stuff. And I'm, like, that is very unapproachable for any dev who does not work at Meta and probably most devs who work at Meta. That's fair.

And then finally, great talk. Are your slides now or later going to be posted online? Yeah. Cool. Follow David on Twitter at David K. Piano. David K. Piano. Thank you, David. Thank you.

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.
Don't Solve Problems, Eliminate Them
React Advanced 2021React Advanced 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Everything Beyond State Management in Stores with Pinia
Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
State management is not limited to complex applications and transitioning to a store offers significant benefits. Pinia is a centralized state management solution compatible with Vue 2 and Vue 3, providing advanced devtools support and extensibility with plugins. The core API of Pinia is similar to Vuex, but with a less verbose version of stores and powerful plugins. Pinia allows for easy state inspection, error handling, and testing. It is recommended to create one file per store for better organization and Pinia offers a more efficient performance compared to V-rex.
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.
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.