How to NOT use useEffect?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.