How to NOT use useEffect?

Rate this content

Are you using React in your project? If so, you must used useEffect! Actually, it’s essential for many use cases, but there are instances where it might not be the best solution, and avoiding it can improve your application's performance.

In this talk, we will learn from experience which is the missing piece of the puzzle to master useEffect. Taking a look at the incorrect cases and trying to improve their performance helps us to have a deeper understanding of it.

24 min
23 Oct, 2023

AI Generated Video Summary

Welcome to how not to use UseEffect. UseEffect is a hook introduced in React 16.8 as a replacement for component dismount and update in class components. It runs your callback once when the component mounts and when there are changes in dependencies. UseEffect allows performing side effects such as fetching data. UseEffect executes its callback asynchronously to allow the browser to render and show something to the user without blocking the main thread. Setting a state in a useEffect without a dependency array can cause nasty loops. Sometimes you are using use effects to take care of calling parent events. Nasty Fetch. Sometimes, when fetching articles, loading and race conditions need to be considered.

1. Introduction to UseEffect

Short description:

Welcome to how not to use UseEffect. UseEffect is a hook introduced in React 16.8 as a replacement for component dismount and update in class components. It runs your callback once when the component mounts and when there are changes in dependencies. UseEffect allows performing side effects such as fetching data.

Let's go! Hey, guys, welcome. Welcome to how not to use UseEffect. Oh, UseEffect is a little bit naughty, so we are going to take a look at it and see how we can use it in the right way and the things that we shouldn't do.

So, as you know, my name is Mohamed, I am Senior Software Frontend Engineer at IO. I'm here because I'm starving for React and JavaScript, so let's get on to it.

So, our journey. Our journey starts with a little bit of history, and then we will answer three questions. What, why, and when. These are critical questions for UseEffect, because based on these questions, we are going to consider some situations and some solutions for those situations. So this is tricky, keep in mind.

So, history. In around 2019, React 16.8, they introduced Hooks Hooks evaluation. So the thing is, UseEffect Hook introduced at that time. Actually, since we were migrating to Hooks in Hooks Flingy, so it was somehow a replacement for component dismount and also component update in class components. So at the end of the day, effectively, much cleaner code in Hook components.

So, first of all, what is it? As you know, UseEffect is just a hook. It has two parameters, a callback and dependency. It is better to rename callback to setup because it is somehow a setup for your effect. Actually, UseEffect is like a Swiss Army knife, so you should be careful. So, a hook that runs under conditions. So under some conditions that we are going to learn, it runs your callback once the React mounts the component, once. As soon as it detects some changes in dependencies, makes sense, we have a dependency array there, so as soon as one of them has changed, and the other one is on each render. These are three situations that a hook, a React actually is going to call your callback. They use effect hook.

So, the thing about useEffect is, why do we have it? Actually, yeah, because it lets you perform some side effects, for instance, fetching data, timers, JavaScript stuff and more. So let's consider the first useEffect callback called by React. The first one is, as soon as React mounts the component once, I guess everybody is familiar with that. So if you pass the second parameter, an empty array, so it's going to run your callback once, and whenever the component mounts to the DOM. So the thing is, in this case we are fetching some articles. Yeah, makes sense.

2. Understanding useEffect and Dependencies

Short description:

We grab entities from the back end, bring them to the front end, and render them accordingly. useEffect detects changes in dependencies and re-renders accordingly. It runs after the first render and again when dependencies change. On each render, useEffect is called without dependencies. It's not recommended to run side effects in the component's body.

So we are going to grab some entities from the back end, from our end points, grab it, bring it to the front end and render it accordingly. So, the second one is, as soon as it detects some changes in dependencies. So, we might have some dependencies for our useEffect. Category ID in this case. We have articles page, we need category ID in this case. So each category ID based on that category ID we should fetch our articles, right? Again, makes sense. So, category ID would be one of the dependencies and we should fetch articles accordingly. So I'm using category ID in my body of my useEffect.

The thing is, useEffect is the thing that happened after the first render, right? This is the initial call, initial render, and then it runs the useEffect. As soon as the category ID change, it's going to render again tree, and again, useEffect. Why again useEffect? Because one of our dependencies has changed. And the other one, last, but not least, to be honest, the thing that happened on each render. Oh, you know, finding... Finding a use case for this might be a little bit tricky. In some rare cases, you might use it, but anyway, it is there. As you have already noticed, there is no second dependency. So it means that the dependency array is undefined, so nothing is there. As you know, undefined and empty array are two different things that are not equal to each other. So, as you see, the first render makes sense. It's going to run useEffect, right? But here, as soon as I set one of my Estates, which leads to a rerender, so it's going to, again, render my component. The whole component is going to rerender. So three, you add the whole component and rerender. Four, calling the useEffect. And it doesn't care about dependencies because there is no dependencies. It's going to run it on each render request by React. So, in this case, setCount caused that. In other cases, it might be a property change or whatever you think of it. So, why do we need it? First of all, it's not recommended to run side effects in the component's body. I guess we have already noticed it a little bit during the things that I was telling you in the previous slide, that as soon as you change something in your component, React is going to rerender your component, your function component. So it's going to run it from top to bottom, top to bottom, top to bottom, right? So if you put something, for instance, fetching articles in the body of your component, so as soon as you change something, it might not even relate it to the articles.

3. Understanding the Event Loop and Promises

Short description:

It's going to recall that function, recall that function, recall that function, fetch articles in this case. We want to fetch articles once. There is a react reason and UX reason behind the scene. React runs the callback connected to event loop. Event loop is a mechanism in JavaScript to handle asynchronous stuff. It works by pushing tasks into the task queue and executing them when the call stack is empty. There is also a microtask queue responsible for promises. Promises can block the main thread by continuously adding tasks to the queue.

It's going to recall that function, recall that function, recall that function, fetch articles in this case. Which doesn't make sense, right? Because we want to fetch articles once. For instance, there is no category ID, but if there is a category ID, we want to render, you know, grab new articles from the backend under one condition, which is category ID has changed. So in other cases, we don't need.

There is a react reason. And UX reason behind the scene, we are going to, you know, dig deeper into those as well. So, first of all, I want you to have an understanding of call event loop, in this case. So when does React run the callback? It is connected to event loop under the hood. And what is the thing? The thing is event loop is a mechanism in JavaScript to handle asynchronous stuff, running JavaScript and almost everything in JavaScript is dependent on event loop.

So how does it work? Take a look at the call stack. Suppose that we are running a function named main. In the main function, we might have setTimeout. We might have a fetch. What are these? We call them Web APIs. Web APIs are the thing that are not, maybe it's better to say that maybe are not part of the JavaScript thingy or it is something that we should request outside. It's better to say. So one of the Web APIs might be setTimeout. One of them might be fetch. So whenever we, you know, request for a setTimeout, there is a duration. As soon as duration passed, there is a callbackFunction for setTimeout, right? It's gonna push it into the queue, which is task queue. So this is important because task queue play an important role in this case. So event loop, as soon as see something in task queue and the color stack is empty, it's going to pop it and put it in the color stack and run it. So, but there is another queue as well, micro task queue. The micro task queue is a little bit tricky because first of all micro task queue is responsible for promises, right? So we have microtask queue and task queue. Task queue is for setTimeouts and microtask queue is for promises. But there is a difference between these two and it is from task queue, it picks one by one, but from microtask queue, it picks till completion. Right? So it plays an important part in our thing. So I'm going to ask you an interview question, which one of these, you know, which one makes the main thread block? I want to block the main thread, which is nonsense, but anyway, which one does that? Based on the thing that we just talked about, Promise does that. Why? Because as soon as it creates, it calls loop in this case, it calls loop and create a new promise. Again, loop create a new promise, right? Because it is an infinite loop in this case, but the thing is, since Java Script event loop, it tries to, you know, complete the whole queue and we are adding to that queue all the time.

4. Execution of useEffect Callback

Short description:

UseEffect executes its callback asynchronously to allow the browser to render and show something to the user without blocking the main thread. It uses Web API, SetTimeout, and other mechanisms to grab information and present it to the user.

It never ends. But in setTimeout, it is a little bit different. Why? Because as soon as it picks one, browser is going to repaint the whole page and pick another one. This is the tricky part. So why I brought that up? Because this is the question right now. So based on this description, does useEffect execute its callback synchronously or asynchronously? Which one? So the answer is asynchronously. Why does that asynchronously? Because it wants to let the browser to render and show something to the user and not block the main thread, right? And give the user the opportunity to see maybe a loading or something. And then with the Web API and SetTimeout and the magics behind that, grab the information and render it and present it to the user.

5. Understanding UseEffect Execution

Short description:

UseEffect executes its callback asynchronously using a task queue. There is a difference between SetTimeout and ZeroTimeout, with ZeroTimeout using a message channel. React source code also utilizes the message channel. The UX reason for useEffect running asynchronously is to allow for immediate rendering and browser paint. There is a synchronous version called useLayoutEffect, which runs before useEffect. It is used when a reference to an element is needed. One situation to be aware of is the 'nasty loop', where setting a state that updates a dependency can lead to multiple network requests.

Cool. UseEffect executes its callback asynchronously. Why? Simple answer. Because it uses task queue behind the scene. I'm not going to say SetTimeout because SetTimeout, it's not quite accurate. There's a little bit different between SetTimeout and another thing which I call ZeroTimeout.

You know, because there is four milliseconds different between running a callback using SetTimeout without an interval, which is zero in this case, and ZeroTimeout, which uses message channel behind the scene. Actually, React source code uses message channel behind the scene as well. You can take a look at its scheduler package of React source code online around 586.

If you follow these lines, you will see that there is a priority check for setImmediate, and then messageChannel, then it looks for SetTimeout, right? So the UX reason was that. So initial React render, browser paint, use effect as soon as you set a state, React renders, and the browser paint. So this is the UX reason is this one, that useEffect runs asynchronously immediately, but asynchronously. Immediately, it means that the duration is zero milliseconds, as we talked about.

So is there any synchronous version of useEffect? Yes, there is. useLayoutEffect is synchronous version of useEffect. As you see, here is our useEffect after browser paint, but before that is our useLayoutEffect. That's very important. So there is a ref reason behind the scene as well. So, as you know, we might want to have a reference to one of our elements. Since React runs everything from top to bottom, so without the useEffect here, we don't have access to the created element. In some not modern, can I say modern, or new frameworks like SolidJS and stuff, yeah, you can have access before that because the compiler does that behind the scene. But in React, since everything runs from top to bottom, it's a little bit different, so we do need useEffect to grab an instance of the element. So everything attached to the body, so they have a reference to the element. So they can give you the current property. So situations and solutions. First one, I call it nasty loop. I guess from time to time you notice that in your network tab, this is a time slice of one second. There are right now 28 requests. Why? Because you are setting a state that updates a dependency. Just take a look at your dependencies.

6. Understanding useEffect and Dependency Arrays

Short description:

Setting a state in a useEffect without a dependency array can cause nasty loops. Objects are reference types and not equal to each other. React compares values behind the scenes. If dependencies haven't changed, it runs the callback once, similar to component did mount.

Or sometimes setting a state in a useEffect without dependency array. Yeah, make sure. The first one, it renders, you know, it's not an infinite loop, but it renders right after each other. We know why it's not an infinite loop, because of the event loop and setTimeout and taskQueue picking one by one. But setting a state in a useEffect without dependency array, it can cause this issue, these nasty loops.

So if you take a look at this snippet, this snippet, you can see that. So we are starting from the top, grabbing articles, setting articles here. Articles is one of our dependencies. And voila. So the question is, articles is equal articles, guys. You know, the content are equal to each other. Both of them contain article one, article two, article one, article two. But the tricky part in this case is that objects are reference types. They are not primitive types. They are not equal to each other, right? So if you want to learn it more, take a look at this question. It could be an interview question. When does React run the callback in these cases? Let's consider it with each other. Use effect without dependency array. Come on, piece of cake. We know that. With a dependency array empty. Fine with me. But what? What's this? So the thing is, you know, we have primitive types and reference types. And what does React do behind the scene? It just compares the values. My question is, is React string equal React string? Of course. So let's go to the next one. So let's answer it first. So they are equal to each other. It means that our dependencies haven't changed, so it's going to run it once. And, you know, component did mount.

7. Understanding useEffect Dependencies and Cleanup

Short description:

Somehow component did mount. The last dependency, an object containing 'label React', causes it to run on each render. The 'nasty async' case involves returning a promise instead of a function, which is not what React expects. Wrapping it with a function async solves this. Lastly, outside the render cycle, cleanup functions are necessary to revert changes made.

Somehow component did mount. So useEffect, the last one, one of our dependencies is crazy. It is an object which contains label React. So how about this case? Not at all. It means that object equals object. No, they are not equal to each other at all because they reference to different parts of the memory. So in this case, it's gonna run it on each render. So it means that this one is exactly like the first one and these two are equal to each other. Why the last one? Because two objects are not equal to each other.

Second, I call it nasty async. So the thing is, we are fetching articles, right? So I want to show off my coding skills to let me use async syntax and make it more fancy. Is it a good trick? In this case, no, not at all, because it's not gonna work. Based on the async function specification, async functions always return a promise. So who cares? Let it return a promise. I don't care, but you should care because there is a cleanup function behind the scene as you know. You should return a function, not a promise. So in this case, if you have a return statement, what does it do? What does your call back? Returns a function. Fine. How about this case? I'm returning one, but no, it's not the one because actually, you're returning a promise that that function would be the result of that promise. So it's not the thing that React looks for. So putting async is not the one. So how to fix it? Yeah, easily. Just wrap it with a function async. It's true that we can't make it async and have a wait, but we can call async functions anyway. So I'm going to call it normally, and we have cleanup functions in this case, which works.

Three, nasty JavaScript. Guys, if you want to do something outside the cycle of, or render cycle of React, for instance, dumb manipulation or adding event listeners to the body or something, or sometimes timers, it's not going to work because you're going to apply those changes, but who's going to revert it as soon as you demount the component? So that's why cleanup function is there, right? So keep in mind that use cleanup function. If you made the background red, just, if it is white or something, if you even clean up the changes that you did. So if it is event listener, keep in mind that you should remove it. If it is a set interval, keep in mind that you should clean it.

8. Nasty state: Filtering articles without useEffect

Short description:

You can filter articles without using useEffect. Instead, use memo to achieve memoization and remove unnecessary useEffect calls.

Nasty state. This is an interesting one. Take a look. I'm trying to filter my articles, right? I have filtered articles. I have articles in the components mount, I'm going to grab all articles. And as soon as search change or articles, I'm going to filter them down based on this search keyword. But the thing is, you can do all these stuff without a use effect. As you know, this use effect, this is a use effect, right? It causes delay and even loop stuff behind the scenes. So let's use another way. So what's the solution? A piece of cake. Use memo. Because use memo runs… I'm writing 11 in this case on the first render if dependencies has changed. Because the first render, all dependencies considered has changed. So it's going to bring you memoization and it's going to remove one use effect for you. Just keep in mind, whenever you see use effect in your component, you might need to consider it because you can easily fix it without the use effect, because you don't need it. Right.

9. Nasty event call and useEffect

Short description:

Sometimes you are using use effects to take care of calling parent events. In this case, you can cut this part and just put it in HandleClick. It's pretty straightforward and easy. As soon as you set this state, open, close would be called and the React render and the browser paint. Less useEffect, more readable, and no extra React render.

Five, nasty event call. Sometimes you are using use effects to take care of calling parent events. In this case, I want to call open and close based on these open, right? But the thing is, couldn't you cut this part and just put it in HandleClick? It's going to work, right? Take a look at the result. I just remove use callback and put it here. The thing is, right now it's pretty straightforward and easy. Let me tell you what happened. It might be a little bit confusing. Take a look. Here, useEffect, cause, running, open, close, and the browser paint happened, right? So the thing is, if you change it, everything, these React render won't happen. And open, close, thing will come here. As soon as you set this state, open, close would be called and the React render and the browser paint. Less useEffect, more readable, and also you don't have an extra React render there.

10. Nasty Fetch: Loading and Race Conditions

Short description:

Nasty Fetch. Sometimes, when fetching articles, loading and race conditions need to be considered. To handle race conditions, a cancellation logic can be implemented using an abort controller. This allows canceling the fetch request if the category has changed.

Nasty Fetch. So this is the last one. Nasty Fetch. Sometimes, you're trying to fetch something, right? In this case, articles. And I think that I considered everything, right? But no, it's not right. I haven't considered loading, let's add loading. So I have a loading state here. Yeah, before fetching articles, loading true. After that, loading false, right? But how about race condition? You know, somebody might click around changing categories and a race condition might happen, right? So let's add race condition logic. So race condition logic, you can do it easily. A variable is canceled true. If it is canceled, don't set our articles. It means that if somebody plays around the articles, it's going to work normally. So the guy will see the latest category ID click. But the problem here is this fetch request has been sent and waiting for the response, let's cancel it as well. The request itself. So I can use abort controller. I have abort controller and I can pass it as a signal to my fetch function and in my cleanup function, I can abort it. So it means that if category has changed, it's going to cancel the previous request.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn