You Are Using useEffect Wrong
Вставка
- Опубліковано 29 тра 2024
- 🚀 Project React → cosden.solutions/project-react
Join The Discord! → discord.cosden.solutions
VSCode Theme | Font → Material Theme Darker | Menlo, Monaco "monospace"
In this video we will talk about how you are uing useEffect wrong in your React applications. So many developers think they understand useEffect when in reality they don't. Instead of doing things the simple way, they opt for introducing useEffect everywhere and increasing the amount of renders and degrading the application's performance. I will show you how to not do that and how to stop using useEffect wrong and start using it the right way.
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👌
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...
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.
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
One of my very rare comments on UA-cam.
Thank you for your videos. Your format is absolutely perfect: short and concise, with supporting examples and precise explanations.
Thanks from France :)
Thanks Cosden, for sharing your knowledge.
For this goldCardCount function, I would use useReducer & dispatch.
This is the exact use case of the useReducer hook I guess.
You’re doing the lords work out here buddy. I’ve screenshotted this for reference. Keep it up 👍🏻
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.
Thank you. A question: In the second example, wouldn't it be good for the handlePlaceNextCard function to be inside a useCallback?
You just earned yourself a new subscriber!
Setround and round value is used in the same place in else block is this correct?
For the Second example do you think that updating the round with setRound then checking its value directly in the second line is correct?
Wow, I'm writing a simple game right now and I'm facing a similar problem. Just in time. Thanks
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.
is it good if I check round count in setRound func ?
Amazing ! i was totally doing it wrongly, thanks man !
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?
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
I've learned something today, thank you sir!
hi codsen if the filter is object it would be infinite loop in useeffect i have tried ?
Btw, how to call the function in the 2nd example.
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 )
Use memo doesn't do async stuff! You still need useEffect to fetch data
Great video, Thanks!
that conditional hell could be avoided with guards for readability
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?
The react documentation is very clear about this: Use useEffect if you are dealing with an external source.
@@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)
You should zoom font or overall screen... Otherwise its hard to see in mobile... Love your tutorials and guides....
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.
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.
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.
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
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.
@@TokyoXtreme I am saying just declaring as a variable, non useMemo
@@TokyoXtreme yeah of you need to deep compare
@@frazuppi4897 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.
@@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
Hey, what is your vs code theme?
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) {
}
}
It will be the same while in this function. Read about it more searching for: "state batching in react"
in the "if(round == 5)" the round variable is not the updated version
But in react 19, they say that we don't have to worry about rerenders... Isn't it?
Everything feels good but isn't it also better to swap this if else hell to guard clauses ?
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.
Use like the example before, with usememo, pass the nextcard and round as parameters
we can call that function in the useEffect with empty dependency or based on the event(like button click)
@@bharathnaidu4636 You could, but then you need to watch the video again, cuz you missed the point.
@@bharathnaidu4636 I hope that's a troll haha
@@o_glethorpe ah yeah that would make sense, thx
Where would you call the handlePlacdNextCard fn?
In the jsx
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.
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.
great video!
Could you use useLayoutEffect?
IMHO, for the second example you can even use useReducer for better state management
Thanks
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.
Why does react still have useEffect if it’s not best for performance? Would it be better to eliminate useEffect from the framework?
Ah yes why sky is blue, google is your answer
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.
I have created a e-commerce website without useEffect
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?
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
i from india . i can't buy . there is a ERROR in payments ." Error confirming with SCA"
check if your card supports USD
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 😊
Why do we even need useMemo in the first example? Won't it work in the same way without it?
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.
@@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.
don't you need to call that function?
He would probably call it in a button to draw a new card, removing the need of a useEffect
So what about React 19 then? They are getting rid of useMemo so useEffect then?
They noticed that React 19 does not include the Compiler.
The Compiler (React.forget) will come long after React 19. So, we've been convinced for a long time that memoization is a neat way to improve React performance.
@@user-qj4rr1rm8i what you on about? react 19 will come with its own compilers thus will no need useMemo stuff
my apps have lots of useEffects and yet no bugs. why? no users - no bugs
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"
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
that processing is unnecessary and doesn't have to be there, so why would we add it ourselves?
@@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
in this case maybe it wouldn't make sense because filterItems is not async but anyways I'm discussing the idea
jQuery don't have problem like this before 😂
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.
Informative video, however, nested if statements is a code smell and in the tutorial you have an if statement 3 levels deep 10:53
It's a simple example, why bother? He could of course just made the first if statement a guard instead; if (!nextCard.isGold) { return; }
Not really, you can always change that anyway to make it "prettier", but the logic is good.
yup, "if (!nextCard.isGold) return" would help get rid of 1 level
@@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.
React Compiler ❤
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.
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.
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
What about useLayoutEffect
It's the same
My thought process is
DON"T use useEffect unless you have a really really good reason to do so.
HTMX >>
that why i use svelte
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
Wat
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?
No, the react official doc also says that don't use useEffect for this type of thing, you are in the wrong here
@@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
@@lord_kh4n 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.
TypeScript and NEXT.js videos, brother
useEffect is the place for bugz
correction, everywhere may contain bugs
@@yawn74 most of that bug in useEffect
First
congrats!