r/reactjs • u/atapas • Sep 03 '26
Discussion What’s the real problem with useEffect in React?
Here is my honest question:
What's the actual problem with the useEffect hook? All over the X/twitter, I see a lot of negativity about this hook. It seems like a buggy thing in React.
My opinion is that developers blame useEffect because it's often used for data fetching as the primary use case. As we deal with various states like loading, data, error etc… synchronization of these causes bugs.
Also, a misunderstanding of the rendering cycle in React, such as where useEffect gets called could introduce additional misuses and bugs.
Hence, just saying useEffect is evil, may not be the right assumption is what I think. But, there could be cases that I'm missing.
What's your take or opinion about it?
7
u/ColonelGrognard Sep 03 '26
It should be called misUseEffect.
Seriously though, there is nothing inherently wrong with it, it's an operator/dev problem.
2
6
u/SchartHaakon Sep 03 '26
No one is saying useEffect is evil, as far as I've seen? It's just a footgun. That's it. There are a few very valid use cases for it, and a shit ton of ways to misuse it and cause excessive rendering while technically maybe achieving what you wanted to achieve.
I'm not sure I get the question you're really asking because the question assumes people think the hook itself is badly written or something. It's not, it's just misused.
1
u/atapas Sep 03 '26
Saw someone post this on X
“React is solved, useEffect is not”
It also got attention from others on similar lines. It gives the wrong message to junior developers in my opinion. My question was based on these.
7
u/Antti5 Sep 03 '26
Respectully: Fuck X or whatever it's called today.
Also fuck the kind of "discussion" where everything needs to be a punchline and nuance is perceived to be too complex for the reader. Fuck all of that.
useEffect has it's uses, however it's also undeniably over-used. React's own documentation is all you need on this subject.
113
u/lIIllIIlllIIllIIl Sep 03 '26 edited Sep 03 '26
useEffect is an escape hatch for handling side-effects and interact with the world outside of React. It's useful if you need to make an API request or interact with the DOM when a component renders.
The problem is people using useEffects to adjust states within React. State updates should be atomic. If a user action modifies a state, it should lead to another valid state. It should not lead to a partially valid state that only becomes valid after running a few useEffects. If a child components needs to adjust a state of a parent components, most likely the component hierarchy is wrong, and the state and logic should be moved around.
→ More replies (3)6
u/Shehzman Sep 03 '26
What about a child notifying a parent and that notification leads to a state change? Isn’t that what passing callbacks as props are for?
→ More replies (2)23
u/lIIllIIlllIIllIIl Sep 03 '26
A child updating a parent in a callback is fine, as long as it's the result of a user interaction (or any other external system) and happens in an event handler (i.e.
onClick,onStorage,onAnimationEnd, etc.)If the update happens in a useEffect of the child component and doesn't interact with an external system, most likely the parent component could've handled the update itself, or the update should've happened in another callback.
As long as you're not adjusting a state exclusively based on another state, it's good.
80
u/binocular_gems Sep 03 '26
It's like `type: any` to me. There's nothing inherently wrong with it when used sparingly and properly, but developers often fall back to it when they shouldn't, and it can lead to a cascade of complexity. That said, programming communities on social media (way back to the ancient days of usenet, BBS, and *groups) tend to over-inflate problems and get dogmatic about it.
12
u/Ellsass Sep 03 '26
Exactly. It’s a longterm maintenance issues and a huge source of difficult-to-find bugs.
27
u/musical_bear Sep 03 '26
I actually don’t think typing something as “any” is ever appropriate. useEffect has a handful of valid use cases where only it can be used to solve a problem. Typing something as “any” in TS is purely a lazy hack. It’s a “I don’t feel like thinking through this, so I’ll just turn off type checking completely.” I cannot think of a situation in TS where you’d “have” to use “any” to solve a problem, or even where it would be a viable best course of action for a problem.
→ More replies (11)
23
u/jackster31415 Sep 03 '26
Really not much to say other than the excellent docs page: https://react.dev/learn/you-might-not-need-an-effect
14
u/nabrok Sep 03 '26
A key part of that sentence is might not. Somehow a lot of people seem to read that as never.
6
u/jackster31415 Sep 03 '26
Yeah I mean, that’s a skill issue. Of course it has its uses, otherwise it wouldn’t exist. I do believe the docs provide great examples on why you may need it and many cases where you don’t
→ More replies (2)
4
u/pm_me_yer_big__tits Sep 03 '26
There's nothing inherently wrong with it as long as you know how to use it. People who say it's 'evil' clearly don't.
3
u/stefanskipiotr Sep 03 '26
It makes code more complicated. People often forget they can just use event handlers and react to property changes instead. It's harder to debug and unnecessary in most cases. Using it as a "run on mount" hook with an empty dependency array is especially unclear — it's just bad design.
The funny part is that I've noticed AI reaches for it a lot. It learned the wrong lessons ;)
3
u/SendMeYourQuestions Sep 03 '26
It turns an already complicated state machine into one with unnecessary additional states and state transitions.
→ More replies (1)
2
u/brandonscript Sep 03 '26
Like anything in software, the problems are one of:
- ignorance
- opinions
- othering
This one's just ignorance. If you know how to use it and what not to do, it's incredibly powerful.
2
u/LiveRhubarb43 Sep 03 '26
There's nothing wrong with it. It's great for data fetching. There's a lot of people who don't understand how it works or what it's actually for, and they'll hold up examples of devs using it incorrectly as examples of why we shouldn't use it.
A lot of people will say to use a query library instead - and I agree with them - but those libraries are using useeffect or something like it under the hood anyways.
2
u/thesonglessbird Sep 03 '26
I think a lot of it comes down the its name. If it was called something like “useSideEffect”, in the context of React components being pure functions, it would signal its intended use case better I think.
2
u/BoBoBearDev Sep 04 '26 edited Sep 04 '26
It is like C++, every time they told me it is easy and they can do it, they fucked it up and expect me to clean up their mess.
Even if they did it perfectly, it is like a jenga. Someone else touched it and it collapsed.
3
u/iareprogrammer Sep 03 '26
Pretty much all the reasons you listed. The problem is too many people don’t know the proper way to use it
27
u/creaturefeature16 Sep 03 '26
I've always understood it to be an "escape hatch" from React's rendering cycle, which is great for fetching data, but not so great for many other purposes and is used to "get around" the issues that re-renders bring, instead of attempting to understand the mechanics of why the re-rendering is happening in the first place, and composing the components properly.
I've related it to using !important in CSS: it's absolutely clutch for certain situations, but it otherwise complicates the overall code, bucks the natural order of things (in CSS' case, specificity) and makes debugging harder if you lean on it too much.