The problem with useEffect

every day I see so many react developers completely misunderstand how to properly use use effect and they're using it in such a way that they're actually shipping bugs in production that are so difficult to debug to actually find the origin of the bug that it's an actual problem and the worst thing is it's not even their fault I can't blame them because there is a real problem with use effect that affects all of us as react developers that we need to talk about so let me show you what I mean we have this component right

here it's called demo and then we have this analytics data variable here which is defined inside of this demo component this variable is an object and has only one property user ID with a value of one we're then using this analytics data variable inside of this use effect right here we're calling the track event function we're calling a page event and we're passing analytics data now in react there is a hard rule that is unfortunately not strictly enforced which states that every time that you define a VAR variable inside of a component like we have

here that is also a non-primitive variable so it's not a string it's not a Boolean it's not a number like it's an object like we have it here and then you go and you use that variable inside of an effect you have to always provide it in the dependency array because it's the rule the problem however is that if you do that if you pass analytics data here analytics data what you're going to end up happening is you're going to cause this effect to run on every single render of this demo compon component because this

analytics data variable being an object being a non-primitive value is going to be different on every single render and as you can see here it's going to make the dependencies of this use effect change which will cause the use effect to rerun and even worse depending on how you have this set up depending on your specific context and your variables you might even cause this effect to run infinitely because it itself might trigger a rerender of demo by setting some state or something and then you're going to have an infinite Loop that that is going

to run infinitely as long as your computer and processor can handle and so it's really unfortunate that use effect itself makes it so hard to do the right thing it makes it so hard to follow the rule that every variable that you use inside of the effect has to go in the dependency array so unfortunately what a lot of developers end up doing is they just don't do it and they remove the variable and they go on their merry way because this is not actually going to break anything because if you think about it this

code inside of this use effect is going to run once on Mount whenever this demo component is mounted it's going to fire this track event function with the correct analytics data which will have a user ID of one right so there's no problem so you can get away with doing it like this and not providing the correct variables in the dependency array now sometimes in some projects you are going to have es lint enabled like I have it here which is actually going to warn you you see here under this array I have this quickly

line if I hover over this it's telling me that we have a missing dependency analytics data what this is telling me is that hey you're using analytics data inside of this use effect here but you haven't provided it in the dependency array are you sure that that's what you want to do currently in my project I set it to war so it's not actually going to trigger an error but in some projects this is set up to trigger an error and so what I've seen is how developers get around that is they'll come here and

they'll do something like this eslint disable line react hooks exhaustive depths doing this will actually disable ES for that specific line and will make the error or the warning completely go away and this is no longer a problem and a lot of developers will argue that this is correct code that this is perfectly fine because there is no buck and they're right there is no apparent buck in the way that we have it currently set up this is perfectly valid and it's never going to cause a bug in development or even in production the problem

however and unfortunately a lot of people don't think about this is what happens when analytics data changes because right now it's static it's just a statically defined variable it's never going to change but what if this changes what if suddenly this became state right let's convert it to state so we'll come here we'll do const analytics data and then we'll do set analytics data and we'll remove this like here and now this is State we'll import State here from react and we'll have everything that we need what happens if somewhere in the code we then

use this function to set analytics data and we change this analytics data value and what's even worse is that realistically this change might not happen tomorrow it might not happen next week it might not happen next month it might not even happen by the same developer it might happen 6 months down the line by an employee that isn't even yet part of the company when that happens what are the chances do you think that they're going to remember to put this analytics data variable inside of this dependency array because now if this is different if

this suddenly becomes user 2 you probably are going to want to fire this function with user two and no longer with user one because you want to track this but if you don't provide analytics data in the dependency array this is never going to get fired and you're never going to receive that event and the thing is it's so easy to do that it's so easy to forget because first of all you've disabled the thing that was supposed to be there to make sure that you never forgot and unfortunately like I said the problem with

use effect is that it doesn't enforce this on you and it will let you gladly not provided and you have to deal with your own bugs in yourself and you're going to ship bugs in production right that's the reality of it you're going to forget about this and you're going to ship bugs in production and you cannot argue that you're always going to remember to put analytics data in this dependency array because this you have to keep in mind is a very simple example we have one variable we have one effect and we have one

dependency array what if you had five variables what if you had 10 variables in this component and you had five different use effects that each had to listen to a subset of those 5 to 10 variables are you really going to tell me that you're never going to forget in in any case while having ESN disabled to always put the correct variables in the correct use effect you're not going to do it it's impossible it's almost impossible and you're very likely going to ship a bug in production and that's a huge problem right that's a

problem that a lot of developers are doing every single day and they're building up the Habit to not provide all of the things that they're using inside of the effect in the dependency array just because react lets them do so and because they probably don't even have eslin setup you need to have eslin set up in your product project it's there for a reason there is value to it and it's going to prevent you from doing rookie mistakes like this that are going to come back to bite you later on because when you eventually do

find the buck right you have to think about it realistically when are you going to realize that this track event isn't fired when this user ID changes right you're going to look in your analytics and you're going to assume that your data is correct which is going to be wrong you're going to have wrong data so you're going to make decisions based off of wrong data and then by the time that you realize this mistake which again is super easy to get in into it's super easy to go through code review you're going to have

to figure out and track this all the way back to here and realize that you have a missing dependency when the solution is just to remove this and then deal with this dependency correctly and the thing is it's actually not even that difficult to solve this correctly in this case where we have state here we can just provide state in this dependency array so we'll do analytics data and that's it state is going to be a stable reference across renders un unless it is changed so this is not going to cause this use effect to

run on every renderer this is exclusively going to run once on Mount which is what you want and then every time this variable changes it's going to run this use effect again there's no problem here if Instead This was defined how we had it before so let's do const analytics data that's going to be like this if we had it like we had before and let's remove this and put it here now this is going to cause an infinite render what you can do is if this variable isn't used anywhere else in the component if

it's only used inside of this one use effect you can just come here take it and Define it inside of this use effect and then get rid of it from the dependency array because this is no longer needed this is a very easy and elegant solution in the case where you're only using this in this one use effect but in some cases where you do have to use this analytics data or any other variable in other places in your component what you can do is you can just wrap this in use memo so we'll come

here we'll do use memo import this and then we'll do like so parenthesis paste it and we'll provide here a dependency array that will leave empty for now if you do it this way this is then going to memorize this value it's going to create a stable reference and that's always going to be the same unless this dependency array changes and then you can safely provide it in this use effect and you're no longer going to have a problem if you have a function instead of a variable you would just have to use use call

back instead and it would work exactly in the same way the thing is unfortunately and I completely agree with everyone that is complaining about this you really really shouldn't have to do this in a react application this is a lot of work and it's a lot of things to think about and it makes it so easy to forget one little step and to shoot yourself in the foot that honestly I completely understand why people are complaining about react because when they're complaining about re is they're complaining about this specific thing you have to have a

use effect you have to manage the dependencies here then you have to create a use memo you have to manage its dependencies and you can go so deep with this that it's so easy to get lost in all the complexity and really it's unnecessary and I completely get when people say that felt or view is doing this better I completely get when people want use signals that don't really have this problem I completely understand it's unfortunate react isn't perfect and there are inherent problems like there is a problem with this use effect but the reality

is if you want to work in react if you want to get a job in web development react is going to be your best bet and the unfortunate truth is that you have to adapt and you have to learn about reac and us it this way because what's the alternative are you going to go use view you can you're probably not going to have these problems but then it might be a lot more difficult to find a job right so it's pros and cons and nothing is perfect and for what it's worth the react team

is currently working on this so this is going to be hopefully a temporary problem they have a hook that is called use effect event which I'm not going to go into this video because it's still experimental but that solves a little bit that problem that allows you to have variables that use inside of the effect without having them trigger the use effect or we might use something like react forget which should just automatically handle the dependencies for you so that you can literally forget about them that is the solution that is what we're aiming and

working towards but until then you have to understand and accept the rule that everything that you use inside of an effect has to go in the dependency array and you have to do the work around it to make that happen properly and not shoot yourself in the foot it's the unfortunate truth you have to do the work and please don't ignore them don't ignore eslint and just make sure that you do it properly because it's always worth it to do the work now because the alternative is you're going to have to pay for this in

the future and it's going to be a lot uglier when you do if you enjoy this video and you want to see more videos like these that are maybe a little bit shorter and kind of talk about a specific thing in react please do let me know please leave a big thumbs up also make sure to subscribe you can click right here it would really mean the world to me also there's a video here that you can watch YouTube seems to think that you're going to enjoy it so I would highly encourage it and that

being said my name has been D caen thank you so much for watching this is caen Solutions and I will see you all in your next video chaa