You Are Using useEffect Wrong

[@gianlucapiccirillo8398]

The reason why some people disagreed is because of the overwhelming amount of beginner/inaccurate content on the internet… which takes away from the ppl who actually know what they are talking about, like u. Great video👌

[@petarkolev6928]

Exactly! Too many incorrect tutorials for beginners on the internet. Where there's no control over the content huge amount of beginners start on the wrong foot which btw haunts them for many many years ahead...

[@xxFyl]

One of my very rare comments on KZbin. Thank you for your videos. Your format is absolutely perfect: short and concise, with supporting examples and precise explanations. Thanks from France :)

[@uquantum]

Awesome...and love your style. How lucky we are to have someone so dedicated to help us code better...even when some viewer/coders believe so strongly that you need useEffect in situations where it actually lowers performance. Thanks so much!

[@paulab9310]

wow! this is amazing, very clear explanation again. OK, so if I understand correctly, if I ever need to implement a component for search I should use useMemo. On the second example, to me, the code you started with is how someone who does not spend plenty of time playing with JS or TS before jumping to React will code. Too many new developers get so excited by how magic react is that they forget the beauty of JS. I like how you cleaned the code and it is so much easier to read. Thank you, and will sign-up to your course.

[@ricohumme4328]

For your first example regarding the use of useMemo one could also say you should not store in state what can be derived from other state variables. If one of the state variables changes, the memoized result gets updated in the same render.

[@AndersGustafsson87]

indeed, I actually found it quite triggering that he said "this is the correct way to do it" multiple times, while showing what react docs brings up as an anti pattern. I mean I know this is just an example, but still, make the example correct also

[@hemanth2780]

Can you explain more on what state can be derived from which state

[@ricohumme4328]

Yes ofcourse, say you have a list of users and you would like to filter those users with a status. You could apply a filter over those users and put that in a const. If anything triggers a re-render, the filter will get re-applied. You now derived data from state. If the list of users is really big or the filter is fairly complex or expensive to do on every re-render, you could store the result with a useMemo hook with a dependency on the list of users. Now the filter will only apply if the list of users changes. Const users = [] // a list of users, lets say 500 Const activeUsers = users.filter((user) => user.active); // or const memoizedActiveUsers = useMemo(() => users.filter((user) => user.active), [users]); Does this help?

[@Gaijin-ks5vq]

@@ricohumme4328 useMemo also causes a rerender though right?

[@davidlintin]

You’re doing the lords work out here buddy. I’ve screenshotted this for reference. Keep it up 👍🏻

[@TazG2000]

An effect is supposed to be an external effect that is triggered by state. In the very last case, I would argue that useEffect should still be used, because the "alert" represents a genuine external effect. I would have "handlePlaceNextCard" only responsible for state updates and keep the "alert" in the effect. Consider a feature is added like this: const { data } = useQuery(...); const isGameOver = round > 5 || data?.isCanceled; Now we have multiple sources for ending the game - the internal logic of the component, or something external like a server reporting that the game ended early. If we had a useEffect on isGameOver, it will still trigger regardless of the source of the state changing, without any additional code needed.

[@FrontNinja]

Wow, I'm writing a simple game right now and I'm facing a similar problem. Just in time. Thanks

[@JohannSiemens85]

Thanks for the video, buddy. As an Architect who only learned coding from a bootcamp, i think all of this is more of an "engineering mindset" issue. I have dealt with a lot of different developers throughout my carreer and in my own company too, so the conclusion i came up with is that a lot of people just want to solve shit and don't even think about potential issues in performance, "clean code" (whatever this means for you who is reading this), maintainability and whatever. They figure out a (a as in ANY) solution and if it works it works, so it's fine. This is even true for "Seniors" (calling them seniors based on pure work experience, not skill/quality), who just don't really care. They build, they get an error, they fix the error, they get another one, they fix this one. It's more like a step-by-step code monkey mindset, rather than thinking on a conceptual/strategic level.

[@yawn74]

The more they should in performance / clean code. If nobody minds / cares about it because of the "time crunch", then your company will touchwood fail due to the inefficient and ineffective coding which leads to spagette codes. Yes you can don't mind the patchwork your company does, the latter part will be it is the future ones that has to keep patching until some drops a nuke bomb to nuke it cleanly and does it well.

[@Gaijin-ks5vq]

Ironic, because the people you describe, in my experience have almost exclusively been bootcamp grads.

[@carlhandy]

You just earned yourself a new subscriber!

[@irfansaeedkhan7242]

love the practical way of explaning things, awesome u r awesome

[@baldcoder_]

If a value can be derived, don't declare it as a state. If a change is triggered by an event, apply it in event handlers. Never ever violate the exhaustive dependency list rule. Stick to those principles, and useEffect becomes the very straightforward escape hatch that it is and life is good.

[@mohitkumartoshniwal]

To sum it up, one should be cautious about putting all the things in state variables and should instead derive things from the state variables as and when needed, then no need to add extra useEffect. The new react docs do a good job in explaining that.

[@abdelrahmanmagdy3706]

For the Second example do you think that updating the round with setRound then checking its value directly in the second line is correct?

[@prayogaluphalithalu4305]

Setround and round value is used in the same place in else block is this correct?

[@kalideb-y3y]

in the second example all the logic inside of "handlePlaceNextCard" function will run based on the current value of the nextCard state not the updated one. I think you still have to use at least one useEffect.

[@leojan7390]

Great explanations! However, I would have liked to see how to call the function handlePlaceNextCard in the second example. Because you just declared it, but it is never called anywhere.

[@o_glethorpe]

Use like the example before, with usememo, pass the nextcard and round as parameters

[@bharathnaidu4636]

we can call that function in the useEffect with empty dependency or based on the event(like button click)

[@o_glethorpe]

@@bharathnaidu4636 You could, but then you need to watch the video again, cuz you missed the point.

[@leojan7390]

@@bharathnaidu4636 I hope that's a troll haha

[@leojan7390]

@@o_glethorpe ah yeah that would make sense, thx

[@ThatWorksOnMyMachine]

Btw, how to call the function in the 2nd example.

[@nguyenhoa7759]

The code in handlePlaceNextCard will be misbehaved seriously. First, goldCardCount needs to be set before checking condition. Secondly, round will not be the latest desired value (after setRound((r) => r + 1)) which leads to the condition results incorrectly. I tried it by debugging value before & after setState in the same function. Please correct me if I'm wrong.

[@TokyoXtreme]

Use useEffect for synchronizing components with external systems outside of React. In this game, the new UI can always be completely derived from the current state (and props too I suppose), which is only updated through user interaction (pressing a button rendered through JSX). It should be immediately obvious therefore, that useEffect doesn't belong anywhere in this component.

[@felipecabreira4321]

Amazing ! i was totally doing it wrongly, thanks man !

[@HwordD]

Could you use useLayoutEffect?

[@NikulPipariya-hg5mb]

You should zoom font or overall screen... Otherwise its hard to see in mobile... Love your tutorials and guides....

[@kashmirtechtv2948]

But in react 19, they say that we don't have to worry about rerenders... Isn't it?

[@pabloberd]

Thank you. A question: In the second example, wouldn't it be good for the handlePlaceNextCard function to be inside a useCallback?

[@RobGeeDev]

that conditional hell could be avoided with guards for readability

[@JavaxTv]

So whenever we need to fetch an API during the first load we should use memo instead of useEffect without any dependency since the useMemo will not need to re-render flickering data? ( got a feel legacy codes using the useEffect way )

[@cosdensolutions]

Use memo doesn't do async stuff! You still need useEffect to fetch data

[@quanganhinh6252]

I just want to ask: In the 1st example, will the useMemo trigger again when another prop other than filters changes? Because "filters" is an object so it will be different every time the props change right?

[@cosdensolutions]

It won't change if anything other than items or filters changes. In this example you can assume filters has been memorized in the parent

[@kamilratynski4988]

Everything feels good but isn't it also better to swap this if else hell to guard clauses ?

[@baldcoder_]

I'm always baffled by the "reputable" tutorials that use useEffect as an event listener. They would change some state in various event handlers and then have a useEffect to react to that state change instead of bundling all the logic in the event handlers. Literally the worst approach to DRY your code. Ridiculously hard to maintain in even mildly involved components. The react docs are excellent on this topic, but the fact that most people prefer tutorials is what led to the mess we have today.

[@yawn74]

9:56 , based on the above logic , when it is 4 and above it resets to 0. ... Hence increment from 3 to a 4 , won't it resets to 0 as well? Therefore shouldn't we check for less than or equal to 2 to increase , if it equals to 3 resets to 0? 11:12, thereafter you have explain what I just wrote indirectly affects.... 11:35, optional but I may break these chained if else into its own conditional, for example: if (nextCard.isGold && goldCardCount 3) { ... if (round === 5) { ... } } Correct me if I am wrong, useEffect should be used for initial calling of API, and detects the change of a variable once. The detect of change is the tricky part whereby I need to reconsider is there another way to do it without using useEffect?

[@o_glethorpe]

The react documentation is very clear about this: Use useEffect if you are dealing with an external source.

[@z-aru]

@@o_glethorpe Very true, useEffect is not for this type of thing, use useEffect for subscribing/communicating something from an external source (API Calls, store libraries that are outside of react ecosystem)

[@SaivivekRavi]

hi codsen if the filter is object it would be infinite loop in useeffect i have tried ?

[@diegovinicius4186]

Programmatcly speaking, isnt good use "round === 5" because weird things can happens, and if somehow your variables go above 5, it wont be trigger, so I still would use >== 5 in that case, just for "sanity check"

[@semajroyam3725]

I've learned something today, thank you sir!

[@awekeningbro1207]

useMemo runs when any value in its dependency array changes, but in order to flush those changes, their needs to be a re-render, no?

[@cosdensolutions]

When any value changes there needs to be a re-render yes, but only one. So only when items changes. That's with useMemo. With useEffect there's 2, when items changes and then selectedItems after that

[@RCEZ-s7u]

Hey, what is your vs code theme?

[@bryson2662]

That first example hurt. Why tf would someone do that instead of just creating a variable based on state that renders on each state change or even better, use usememo.

[@coderkrishna8990]

Sure, we are reading the updated round variable value immediately after updating it in the else statement ? Please explain me this part ..... else { setRound(r => r + 1) setGoldCardCound(0); //HERE - is it the same round value , after incrementig it ? if(round == 5) { } }

[@tamirlangabaraev7130]

It will be the same while in this function. Read about it more searching for: "state batching in react"

[@kalideb-y3y]

in the "if(round == 5)" the round variable is not the updated version

[@dianab536]

Why does react still have useEffect if it’s not best for performance? Would it be better to eliminate useEffect from the framework?

[@yawn74]

Ah yes why sky is blue, google is your answer

[@TokyoXtreme]

The hook is designed to synchronize components with external systems - outside of React. If you have to fiddle with browser APIs or other side effects, then that's why you'd use useEffect. In the example here, of the card game, there is only the loop of user interacting via JSX UI elements (buttons, probably), which update state and trigger a re-render. The new UI can be completely derived from the current state, so it's glaringly obvious that useEffect is not needed. Perhaps if cards were being saved in browser's localStorage, then useEffect would be needed.

[@lastink444]

my apps have lots of useEffects and yet no bugs. why? no users - no bugs

[@youstead]

IMHO, for the second example you can even use useReducer for better state management

[@ThomazMartinez]

So what about React 19 then? They are getting rid of useMemo so useEffect then?

[@ThomazMartinez]

@@풍월상신 what you on about? react 19 will come with its own compilers thus will no need useMemo stuff

[@ДмитрийКалганов-ю6э]

is it good if I check round count in setRound func ?

[@vekeryk]

Why do we even need useMemo in the first example? Won't it work in the same way without it?

[@chrisjohanesen]

You don’t need it, but the useMemo will save the result so the function isn’t called on every render unless the dependencies change. Probably only needed if the function is doing a lot of heavy processing.

[@vekeryk]

@@chrisjohanesen Got it. I just wonder if render will be affected differently with useMemo. I mean, if we have only filters and items as props/state then UI will be rendered anyway.

[@matthieudantes4129]

first exmple: you are talking about the number of renders, but not about the momory you are using for the useMemo, React senors developers only advices to use Usememo for big functions, in your example, use effect would be better. In your seconde exemple, its cool to refacto all the code, but you are not using the function that you created, so how you do to call it and synchronize with your contexte (useeffect) useeffect => synchronisation with your context, that's it but forbidden for the request => use react query instead

[@Dom-zy1qy]

Wat

[@TokyoXtreme]

useEffect is meant for synchronizing with external systems outside of React - so which external system is being synchronized here? There's nothing that can't be derived from user interaction, props, and state, so there's no need for useEffect. Can you answer which "side effect" needs to be synchronized?

[@z-aru]

No, the react official doc also says that don't use useEffect for this type of thing, you are in the wrong here

[@matthieudantes4129]

@@TokyoXtreme in the new doc they advice it, in the old doc they didnt... Its a fact React query is the most powerfull process to fecth datas, forget useffect for this use case

[@matthieudantes4129]

@@z-aru i am just speaking about "cost",some time you dont have other choices to use useeffect or useMemo, But the memory cost is sup than rendering. Its why you use it, only for function/variables using a lot of power.

[@Ayyanar-o3n]

i from india . i can't buy . there is a ERROR in payments ." Error confirming with SCA"

[@cosdensolutions]

check if your card supports USD

[@ivan4486]

don't you need to call that function?

[@gabrielkyomen4782]

He would probably call it in a button to draw a new card, removing the need of a useEffect

[@aliarefjs]

Great video, Thanks!

[@troglodytto]

My thought process is DON"T use useEffect unless you have a really really good reason to do so.

[@yassine-sa]

4:00 why is it a pitfall? Maybe it's better to do it this way and show a loader while the data is loading/being processed

[@cosdensolutions]

that processing is unnecessary and doesn't have to be there, so why would we add it ourselves?

[@yassine-sa]

@@cosdensolutions I agree in this case it's just a simple filter, but maybe the filtering is done on the server side, this way we have to wait for the data to load I think, so it depends

[@yassine-sa]

in this case maybe it wouldn't make sense because filterItems is not async but anyways I'm discussing the idea

[@SR_77756]

Hey cosden, Can we expect some discount to u r project react course, it will be helpfull for students out there including me who want to purchase this course. Thanks 😊

[@fra4897]

thank you so much, stupid question :) what if I just to const filteredItems = filterItems(items, filters) and that's it? Since we will rerender when props changes so that should be correct

[@TokyoXtreme]

The reason is for increasing performance, which is not always needed, and I've read that using useMemo itself creates a set amount of processor cost, which may often be greater than the un-memoized function. In your example, the filteredItems variable will be computed on every single render, even if items and filters had the exact same value on the previous render, making the re-computation unnecessary. When useMemo is applied, the computed value will not be re-computed during the render - instead the previous value will be used. If there are thousands of items in that items variable, you will definitely notice an improvement in the UI responsiveness. There are examples in the new React docs that demonstrate the difference that it makes. But if you knew that items was always a fixed value, like a set of 15 colors or something, then maybe it would be faster not to use useMemo, because of the overhead cost that it requires. Or is said to require, I should say.

[@fra4897]

@@TokyoXtreme I am saying just declaring as a variable, non useMemo

[@fra4897]

@@TokyoXtreme yeah of you need to deep compare

[@TokyoXtreme]

@@fra4897 filteredItems is a computed value, which doesn't have to be memoized; but if the calculation is costly and time-consuming, then memoizing will increase performance noticably.

[@fra4897]

@@TokyoXtreme no beucase it will rerun only if the props changes, thus is If just have a computed value will be the same since in that case the components will rerender I guess

[@_bestbeast]

I have created a e-commerce website without useEffect

[@dawiddudek774]

Where would you call the handlePlacdNextCard fn?

[@LuKaSSthEBosS]

In the jsx

[@aymanechaaba]

React Compiler ❤

[@julianvargas228]

great video!

[@codingwithzak09]

Informative video, however, nested if statements is a code smell and in the tutorial you have an if statement 3 levels deep 10:53

[@johanrg70]

It's a simple example, why bother? He could of course just made the first if statement a guard instead; if (!nextCard.isGold) { return; }

[@programmers_sanctuary]

Not really, you can always change that anyway to make it "prettier", but the logic is good.

[@alohadev369]

yup, "if (!nextCard.isGold) return" would help get rid of 1 level

[@yawn74]

@@programmers_sanctuary here watch this video in aspects of chaining if else v=EumXak7TyQ0. Not a spam, just that on a neutral perspective the true objectives for a developer besides developing features / solving bugs are: 1. Readable code. 2. Can the code be simplified to understand easily? 3. Should this code be a function as it is being repeated? 4. etc.... If your mindset is just content to solve codes, the others hope that it isn't long and spaghetti.

[@ichiroutakashima4503]

The fact that there's an ongoing war between programmers on which case is better yet most of the time, the client just doesn't give a f about how you made it, they just want you to deliver is hilarious.

[@yawn74]

Tbh, clients are idiots that they bargain towards marketing / client service group. But the root problem lies internally, whereby the boss / higher ups doesn't care after patchwork of projects how do we as a programmer do small steps to not create more problems. That is the real issue.

[@z-aru]

But Clients care about speed, using useEffect for this thing would add 1 more render to the component, this render will give another overhead and affects your overall app speed

[@prashh47]

HTMX >>

[@YuraZavadenko]

What about useLayoutEffect

[@MsSoldadoRaso]

It's the same

[@JohnBrianPrado]

Thanks

[@shravananto6107]

TypeScript and NEXT.js videos, brother

[@HoangDuck666]

that why i use svelte

[@JovenAlbarida]

jQuery don't have problem like this before 😂

[@programmerjowo]

useEffect is the place for bugz

[@yawn74]

correction, everywhere may contain bugs

[@programmerjowo]

@@yawn74 most of that bug in useEffect

[@codingwithzak09]

First

[@cosdensolutions]

congrats!