1. Introduction to UseEffect
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, 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.
2. Understanding useEffect and Dependencies
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
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.
4. Execution of useEffect Callback
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
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
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
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.
8. Nasty state: Filtering articles without useEffect
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
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
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.