Why you probably do not need useEffect

[MrPlaiedes]

Can we just recognize trial and error and learning from your mistakes? Respect.

[pesterenan]

This was a great lesson on why you needed to refactor your code. You saw the problem, you've implemented your way of dealing with it, using useEffect, and then you saw how to improve on it!
I say this is great because I'm dealing with legacy code, and the logic approaches more with not needing an useEffect, but rather a derived state that just changes inside it whenever something changes.
It's harder to wrap your head around first, but then it just looks not only cleaner, but helps when the app gets more features for example. Nice video Cody!

[JThompson_VI]

It can be easy to forget, reactive state changing not only causes the the ui to update but causes the whole component to rerun. So any function or non reactive state reliant on reactive state will change.

When I am tasked with fixing a react bug, the first thing I do is check for a useEffect.

[armandsalle]

The second version is what I would have done (mixed with the setState(prev => ...). The derived state is great for performances but a little bit harder to read for humans, so I think it depend on the complexity and the performances you need

[xvzf]

That thread on your previous video was very educational. Kudos to the person that started this discussion!

[dcmbassi]

I zeroed in on that doc article as soon as it went live. I've been freeing myself from overreliance on useEffect ever since.

[abgezuckert.]

I would consider that state is typically used for rendering stuff. And what is concretely rendered here? Either the numpad or the message. So imo the only state this component should have is the message string. Neither an isError bool where you have to derive the message from nor the pressedNumbers which are not visually represented, but rerender the component unnecessarily on every button click. So all you need is a by default null or empty message string state that gets updated by the click handler with a success or fail message after the necessary conditions can be evaluated (pressedNumber.length === 4 etc.). With !!message you render the state string, otherwise you render the numpad. Simple.

[yzz]

This is why I use a state manager like Zustand.

[Dom-zyqy]

I feel like useEffect just sounds super intuitive to use because of how we think of processes as humans. Semantically "do this as a side effect when X changes" just sounds more... "complete?". Its often times more bloated code (and sometimes leads to broken code) but for me the first thing that comes to mind when im writing code like this is: "how can i achieve X running when Y changes, kind of a "side effect of something happening", oh yeah react basically has a hook for this! "

[TheSocialDeveloper]

Nice! You updated this! Couple more suggestions, although I wouldn’t go back and change anything, adding “idle” to state makes more sense for initialization. When I think of verbs ending with “-ing” I think of something happening currently, at which point you’d debounce before updating state back to “idle”. That’s really it from me. Great video!

[butwhothehellknows]

Lol when you said “you should read this article” I chuckled and said “I bet Cody skimmed it at best” lol sure enough that’s what you said right after hahahahaha love you babe! You’re doing great

[adarsh-chakraborty]

I get it, Not using useEffect is good but I would still use 3 different state variables instead of checking for state of one variable at multiple places

[okage_]

was waiting for this after i read that comment haha
glad you made it a video and broke it down

[UmairSadaqat]

Great but I think is too much rendering when you are using the last approach because whenever this component is rendered is always buggy with if-else statements

[Slde]

I would only use the state to display the end result, not store the entered numbers in it. and I would store the entered numbers with useRef so there is no re-rendering for every input. and on the last input, check if the password was entered correctly and change the final state to pass or fail

[anuj]

Thankyou for great explanation. Please bring more tutorials on how to prevent re rendering and slow issues?

[omega_sine]

Would this be a valid use of useEffect:
I wanted to extend this challenge and allow the user to type an answer using the keyboard. I believe react provides onKeyPress or something similar for key presses, but when using that it seems that the user must be focused on the specific element. I wanted to be able to listen for key presses even when you’re not focused on the element. So I ended up using useEffect and registering an event listener on the document itself which would call the set function that I got from useState. I also had to make sure to remove the eventlistener afterwards, otherwise there would be multiple listeners for a single key press. It worked fine but I wonder if there was a more elegant solution.

[petermckeever]

Moving to a handler instead of useEffect definitely the right call. Don't know if i would completely remove useState though

[LuKaSSthEBosS]

How do you do this renaming thing at 6:00?

[waytospergtherebro]

A function called "useEffect" which performs 30 different tasks depending on the number of empty arrays you pass in to it is much, much, much easier to understand than component lifecycle methods that do the one thing they say they do and if you don't believe that then you are not a real Millennial engineer.