You Are Using useEffect Wrong

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.

[gianlucapiccirillo]

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👌

[xxFyl]

One of my very rare comments on YouTube.
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!

[ricohumme]

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.

[davidlintin]

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

[paulab]

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.

[JohnnyHandsome]

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.

[TazG]

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.

[prayogaluphalithalu]

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

[FrontNinja]

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

[carlhandy]

You just earned yourself a new subscriber!

[yawn]

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 (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?

[ThatWorksOnMyMachine]

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

[abdelrahmanmagdy]

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

[leojan]

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.

[kalideb-yy]

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.

[irfansaeedkhan]

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

[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.

[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

[nguyenhoa]

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.