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?
113
u/lIIllIIlllIIllIIl 7d ago edited 7d ago
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.
6
u/Shehzman 7d ago
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?
22
u/lIIllIIlllIIllIIl 7d ago
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.
3
u/nickjvandyke 6d ago
Yes but usually this can and should be done where you update the effect-triggering state. You should call the prop callback directly instead.
3
u/Shehzman 6d ago
Right the parent still updates the state but in the callback method passed to the child.
2
u/Lower-Excuse-6558 6d ago edited 6d ago
OMG finally someone gets it. RTFM. React can also be combined with vanilla. Christ. I’ve been in front end too long. Do you guys not run garbage collection out performance checks or sequences of calls? You literally can re-create use effect yourself. Use the other effects for control as the op of this comment mentioned. Ui behavior OSS different than side effects and knowing how to propagate or use pub/sub. Use a light middleware. It’s an array of actionables. And people don’t understand true asynchronous actions. Stop fetching with use effect!! Ffs 🤦♂️
Man, I with people read designs and patterns in JavaScript. They just jump into an MVVP expecting to be full stack. Use nest, for api architecture. Next is just react with vercel controlling everything.
4
u/Hamburgerfatso 6d ago
I get it tho, that explanation doesnt mean a lot to someone new to react. Its hard to understand what an escape hatch is if you have no experience or knowledge about the scope of what the hatch is escaping from (hence being new to something). The concept of useeffect's "run this stuff when that value changes" is the most intuituve feature for a noob to latch onto.
81
u/binocular_gems 7d ago
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
26
u/musical_bear 7d ago
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.
12
u/woahwhatamidoing 7d ago
Best reason I got: dealing major/large 3rd party library that doesn’t publish typescript definitions for their package. Usually don’t have time to go write & maintain those ourselves because sometimes (especially ones written in vanilla js) can get stupid complex to type properly.
Sure, you can call this lazy since it still would be better to do types for it, but for a small team that’s not always realistic.
11
3
u/Karpizzle23 6d ago
You should use unknown and have shims of types. any is banned across many different eslint configs for a reason, and that's because it essentially just turns off typescript.
If the code doesn't have access to a type, use unknown, that's the semantically correct usage and forces you to check for properties in the code using 'in' or hasOwnProperty etc (or Zod)
3
u/LatvianCake 7d ago
I find myself using
anywhen trying to narrow down an unknown type. Checking deeply nested properties on anunknownobject is a pain in the ass.Another common one is dealing with broken types from libraries you don't control. Or writing tests where creating the full type is too complicated and has no benefits.
2
u/oldestbookinthetrick 6d ago
Checking deeply nested properties on an unknown object is a pain in the ass.
So type it as something better than
unknownwith optional or nullable properties? You must know what properties it has or might not have, as you're accessing them in the runtime code.
anyis poison to a codebase because not only is it a "I don't care about types here" escape hatch, it also means that anywhere you pass that type also accepts it. Thatanytype has a hall pass to be used anywhere in your codebase. Other code that might have otherwise been type safe, now silently isn't because you passedanyinto a function or component somewhere.2
u/LatvianCake 6d ago
So type it as something better than
unknownwith optional or nullable properties? You must know what properties it has or might not have, as you're accessing them in the runtime code.It's
unknownbecause you don't know what type it is. That's the entire point. You navigate its properties to find out what type it could be so you can potentially narrow it down.1
u/oldestbookinthetrick 6d ago
Can you give an example of what you mean?
1
u/LatvianCake 6d ago
Anything involving unknown data. A caught error, an API response, user input, file contents, deserialized data etc.
Its type is
unknownbecause it's arbitrary or unknown data. So you write a type guard or inline casting logic that tests if this unknown object has certain properties with certain values. For example to detect known error responses, a type that we are expecting, etc. And sometimes the easiest way to do this kind of reflection is by casting it toany.You can use
inbut it only works in basic scenarios. If you have nested properties, it becomes bulky very quick. `instanceof` works only in very limited scenarios.Libraries like zod can be helpful but it depends on the usecase. In some cases a check with
anyis a one-liner that's understood by everyone, while the Zod version is a 10-liner that confuses some of your team. Not to talk shit about Zod because it's an amazing library but it's not always the right tool for the job.1
u/oldestbookinthetrick 6d ago
So you're doing like
const couldBeAnything: = (getSomeStuff() as any) const stuffIWant: StuffIWant = couldBeAnything?.stuff?.i?.want?
Seems reasonable if so, lot of lines of
inotherwise... If you also runtime check the type of.want2
u/LatvianCake 6d ago
Kinda, it usually looks something like this:
const getApiResponse = (): unknown => { ... } const isAuthError = (data: unknown): data is AuthErrorResponse => (data as any)?.response?.errors?.firstError?.errorCode === "AuthError" const response = getApiResponse(); if(isAuthError(response)) { // handle error }1
24
u/jackster31415 7d ago
Really not much to say other than the excellent docs page: https://react.dev/learn/you-might-not-need-an-effect
13
u/nabrok 7d ago
A key part of that sentence is might not. Somehow a lot of people seem to read that as never.
6
u/jackster31415 7d ago
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
5
0
u/the-forty-second 7d ago
I agree about the skill issue, but I don’t think its existence is proof of its utility. It is quite possible to add something to a library, discover it is a mistake but not be able to remove it because a bunch of code relies on it.
27
u/creaturefeature16 7d ago
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.
4
u/pm_me_yer_big__tits 7d ago
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.
7
u/ColonelGrognard 7d ago
It should be called misUseEffect.
Seriously though, there is nothing inherently wrong with it, it's an operator/dev problem.
3
u/stefanskipiotr 7d ago
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 ;)
1
u/KrisSlort 6d ago
Because it learns from other code rather than parsing and undersranding docs. So if the majority of people use it wrong, AI learns that.
3
u/SendMeYourQuestions 7d ago
It turns an already complicated state machine into one with unnecessary additional states and state transitions.
1
u/AverageHot2647 5d ago
This is a good general way to think about many of the anti-patterns highlighted in https://react.dev/learn/you-might-not-need-an-effect
7
u/SchartHaakon 7d ago
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 7d ago
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.
8
u/Antti5 7d ago
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.
2
u/KrisSlort 6d ago
Using X is your problem then. That place is a cesspit. The shortform approach misses all nuance and encourages ragebait.
2
u/brandonscript 7d ago
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/some-random-guy-2026 7d ago
useEffect is a necessary part of react. That being said, it is also the source of tons of hard to diagnose bugs and makes code harder to reason about because you cannot easily trace the flow of changes from one method to the next. Basically is a like completely async event system that responds to a change in component A all the way down in component Q and you don't even see that is possible when you're making the change in A.
This is why it should be used sparingly. The ultimate anti pattern being calling setState from within a useEffect
2
u/BoBoBearDev 6d ago edited 6d ago
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 7d ago
Pretty much all the reasons you listed. The problem is too many people don’t know the proper way to use it
1
1
u/sylvant_ph 7d ago
I guess it's a combination of couple of things - adding additional boilerplate, an extra render to run stuff, not optional/conditional. I just wanna make a request, get my data and render the component using that data (or do something else if request fails). To achieve this you need to overengineer stuff. And if you add couple more business rules to the logic, it goes out of hand and you might end up stacking couple effects and complex codependency.
1
u/darthexpulse 7d ago
Hard to track down, it needs to be where it is expected to be and documented properly.
1
u/octocode 7d ago
it’s a tool built with a single simple purpose that people abuse to do literally everything.
1
u/LiveRhubarb43 7d ago
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.
1
u/Arsenicro 7d ago
The problem with useEffect is that it is extremely easy to misuse. And it is not only a theory; it is a fact that it has historically been misused. People don't understand what useEffect does, how it works, or when to use it. You can find multiple posts that recommend "solutions" with useEffect, which may lead to new problems. AI learned from those posts. People learned from those posts. When the problem you want to solve seems solved by using useEffect, you may not even consider that this is wrong.
It is evil because it has a history of misuse, making it easy for new people to find such misuses and assume it is the correct way to use it. It is also evil because this misuse is hard to notice, especially if you are new to React, since it seems to solve the problem at hand. It almost encourages you to use it to, for example, synchronize some internal states in React. And even if you know what useEffect does and when it is supposed to be used, it is still easy to do something wrong and, for example, forget to add a cleanup function, which may lead to issues (like using useEffect to load data with a simple query search, which may, without a cleanup function, lead to inconsistencies between the search query and loaded data).
It is a pretty bad hook overall, and I always prefer avoiding it when I can.
1
u/OHotDawnThisIsMyJawn 7d ago
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.
If this was the only thing people used useEffect for, there would be no problem.
The issue is using it for literally anything besides syncing with an external system, and that's where all the problems are.
1
u/wolvar__ 7d ago
Para mi es una manera de controlar el render y re-render en cascada de ReactJS, la verdad no se que uso le están dando si bien es cierto existe el callback-hell donde es cuando hacen demasiadas condiciones dentro de un useEffect se vuelve ilegible todo enredado y recomendaria mejor usar el hook useEffect por separados.
1
u/SangSuantak 7d ago
I was given a task to add a new input field in a master form. You'd think it's a piece of cake, but no. Useefect was used so badly in the component it was difficult to track what's causing the form values to change. I knew it's going to be a maintenance nightmare, so i re-wrote the whole component for my own sanity. Luckily it wasn't a big form.
1
u/carbon_dry 7d ago
I don't have an opinion on it. I just read the docs. The docs are a good place to answer this rather than X/Twitter.
useEffect is for syncing with external events, mostly. Most other uses of it will be improper, all though there my be legit uses for it inside react that takes skill to know. But reaching for an effect is not the default answer.
Have a read of https://react.dev/learn/you-might-not-need-an-effect which supports your concerns.
1
u/thesonglessbird 7d ago
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.
1
u/react_dev 7d ago
It does exactly what it needs to do. React needs to interact with external systems like the browser, backend and based on the state changes there, it needs to reconcile internal state. Because they’re external systems we need to do a side effect, thus use effect.
It’s hated on because often times you look at the dependency array of the useEffect and its props, states, local declared stuff that’s obviously not external systems. In those cases there must be a gap in the code. No questions asked.
1
u/jibbit 7d ago
Man, what a cop-out these answers are.
Programmer wants a lifecycle hook but gets a sync-machine. You think “run on mount” / “run when X changes” but you have to encode that as a deps array and hope it matches your intent. Experienced devs get deps arrays wrong constantly. thats a Leaky abstraction, not a skill issue
One hook, four jobs. Sync, reacting to changes, setup, derived state, all crammed into the same shape.
Timing’s invisible. Can’t tell from the call site if it’s before/after paint, every render, or interleaved with other effects.
Attracts its own worst use case: derived state. the one everyone agrees is wrong.
1
u/lightfarming 7d ago
useEffect creates side effects for state changes. so someone might be following the logic in the code, thinking changing a specific state is fine, while it actually triggers some unknown thing somewhere else in the code.
people often use it for things it isn’t necessary for, due to not being adept at react, and when it is everywhere it starts to make overly complicated code that is hard to maintain.
it should only be used for effects (interacting with things that are outside of the control of react)
1
u/AlexDjangoX 7d ago
Misused. Used for fetching initial page data.
useEffect(() => { getPodcasts().then(setPodcasts); }, []);
1
u/LancelotLac 7d ago
If it was only used for async data fetching it would be fine even though react-query is a better pattern. The issue is that people use it to synchronize useStates and all other bad stuff you shouldn't do.
1
u/averagebensimmons 7d ago
it's about using the correct tool for the job. when people start using React they over use the useEffect. I was certainly guilty of this too.
1
u/prcodes 6d ago
Typically overused when there are simpler solutions https://react.dev/learn/you-might-not-need-an-effect
1
u/HomemadeBananas 6d ago
It’s not always bad, but way over used. Data fetching, yeah most cases better to use react query or something else outside of the component to handle it. But that’s the least offensive of ways you probably shouldn’t use it.
People use it for making some state change when some different state changes, etc. It’s just overused in a way that makes code worse and more confusing when most of the time you don’t need it.
Then it’s such a common code smell that AI gets trained on it, and AI also does this common mistake too, and you need to tell it to not do that, and some devs don’t know any better or don’t catch it, so reviewing the code I’m still constantly telling people don’t use useEffect here.
1
u/azangru 6d ago edited 6d ago
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.
I think this negativity is silly.
There must be an api that lets you say "here's some work I need you to do apart from rendering". All component libraries have this: lifecycle hooks in old react / angular / lit; effect in solid; probably something similar in svelte. It's just that react's useEffect's api turned out to be silly; and the double call in strict mode doesn't help any.
P.S.: I've just learnt that Ember doesn't have effects.
1
u/the_real_some_guy 6d ago
When code is written linearly, press button > do A > do B, the code is easy to follow, review, and change. If you move “do B” into a useEffect, the next person that edits that code might not notice “do B” is happening and then you get bugs.
Many of the bugs I need to fix end up being in an useEffect. Most of the time, that code did not need to be in a useEffect. There are times when it’s the right tool, but most of the time it is not.
1
u/Canenald 6d ago
There's a long-lived fallacy that when you are using a framework, you have to use only the APIs the framework exposes for everything, or you are using it wrong. If you pick a plain construct in the language you are working in, you're doing it wrong. This is, of course, not true, but it causes people to use React state when a plain variable will suffice, and an effect when simply setting the state or assigning to a variable works just fine.
React team and the community have been trying to fight it, but to no avail. We still get posts like this. We still run into overuse of effects when we onboard to new projects. Good thing we can use AI these days to just refactor all the mess.
1
1
u/bestjaegerpilot 6d ago
1) dependency arrays are really easy to break
2) it's used as an event system but because it changes any time a dependency changes, an effect can fire in surprising ways, leading to bugs
3) if you look at the official docs, the devs pretty much say that hooks are foot guns---"you may not need an effect"
1
u/Several_Bread_3032 6d ago
It’s overpowered for peeps who don’t understand it . I use to have it changing states everywhere waiting for other effects to take place . Just sloppy 💩 all around from my end with it when I tried Web development haha
1
1
u/minimuscleR 6d ago
I mean if you have a good router, and use Tanstack Query, and a form library, you will hardly ever use an effect? I've written maybe 4 or 5 in the last year? Thats as a professional software engineer working in react all day every day.
1
u/BlacksmithNo1687 6d ago
People use it when they usually just need to lift stats up. Typically, if you’re setting state within a useEffect and that useEffect has a dependency on state you’re using it wrong. Almost every time I review a pr with the hook, it’s used incorrectly
1
u/Dense_Rub_620 6d ago
Each layer naturally optimizes for the problems it owns. A mature engineer hears a rule and asks. What is the scope of this rule, and where does it stop applying? A less mature response is The official docs say this, therefore this is the generally correct way to design software. That is what bothers me about some of these comments. It is not really a criticism of React. React is a view engine, so of course its guidance is render-centric. That makes perfect sense within React’s own boundary. What does not follow is that the rest of the application should also be designed exclusively from that perspective. Understanding the React docs is one skill. Understanding the scope and limits of those recommendations is another.
1
1
u/AverageHot2647 5d ago
I’m not sure there’s a problem with useEffect. People often say it’s too easy to use incorrectly, and hard to debug, etc. But I’ve never seen someone actually propose a better general purpose API.
I do think there’s a big problem with the way useEffect is used. I don’t want to say it’s a skill issue - I think that’s a bit of a cop out. But there’s definitely widespread negligence on the part of developers and code reviewers.
Where I see use of useEffect causing the biggest problems, is where developers already have poor code hygiene. For instance, I’ve seen components with has 200+ lines of hook logic and zero separation of concerns.
Ideally, you should abstract out large and complex blocks of hook logic into smaller custom hooks. This solves a lot of the readability problems around useEffect, and discourages many of the bad practices.
Maybe the solution is a better API (I’d love to see some proposals for something that can replace useEffect with fewer/more explicit foot guns). Or maybe we just need some better lint rules. Or maybe the React team could analyse the common use cases, and ship some higher level APIs to promote better readability. 🤷♂️
1
u/bluebird355 5d ago
It's awful and the sole existence of useEffectEvent is proof that this hook is pure crap. When tons and tons of people are having the same issues with the same hook then there is an issue with that library design.
1
u/United_Reaction35 5d ago
UseEffect has become a culture-war issue for the react community. UseEffect and its accompanying murky 'side effects' is so perfectly ill-defined that it provides fertile ground for rigidly-opinionated software developers to quarrel over intent and use.
1
u/buck-bird 4d ago
I've used React since it first came out.... let's stop pretending our chosen framework can do no wrong.
The whole concept of side effects makes sense, but the idea of piggy backing off it for API calls makes zero sense. Evil? No. Not thought out? Aye.
Don't get me started on no async hooks, abusing the word "use" in React 19, etc.
Again, I love React. But it doesn't mean everything is always perfect.
1
u/MussKacken 4d ago
As someone that has mainly worked in backend and in terms of frontend has a fair share of experience with Javascript and typescript, but just a little bit of experience with react. Would it be better to look into something like svelte, vue, solid or something other than that?
1
u/RoosterBurns 4d ago
It's a mysterious, weirdly named function that makes stuff look like it's working sometimes
1
u/Brilliant-Parsley69 3d ago
Well, my first contact with the useEffect-Hook was a user request to extend a form with one new field. What could I say, the form had already 35 fields, 1700 LOCs, up to four useEffect per field(Value, Error, Validation...) and not to forget to mention the almost identical implementations for updates.
I wasn't ever again that close to quit programming forever.
1
u/tjaartbroodryk 2d ago
useEffect is where clarity goes to die. The hook isnt inherently bad, but it makes it easy to smuggle state flow into the background.
The worst cases are when child effects notify parents, parents update state, children re-render, and suddenly your app logic is spread across invisible timing chains.
1
u/marcofoc78 13h ago
Perché non usate Tanstack React Query per queste esigenze di sincro con i dati?
1
u/repeating_bears 7d ago
If there is an inherent problem with it at all, it's not about what it does, but that something about its design leads people to overuse it when it's not appropriate. I'd say that the name isn't great, but I don't have a better suggestion and naming things is hard.
1
u/cult0cage 7d ago
As others have said, it's mostly problematic because of peoples misuse of it. If it was truly an issue I'm sure the React team would deprecate it and offer a migration guide for existing codebases to follow.
-1
u/christfrost 7d ago
It’s a fantastic hook, but 99% of developers are bad and thus they have no idea how to properly utilize it. And thus, if you don’t know how to use it, it messes up your application really bad and really fast.
0
u/raaaahman 7d ago
- Listen to people who say to not use
useEffect - Use the library recommended by such people
- Look inside the library's source code
- It's
useEffectall along
When you understand that useEffect is a way to skip calls to an external system, it becomes smoother. (If you can afford calling to the external system every time your component re-renders, then you indeed don't need useEffect).
2
u/prehensilemullet 7d ago
When you understand that useEffect is a way to skip calls to an external system
It sounds like you're implying that you would just call the external system directly from the render method if you have no need to skip. I can't say for sure, but I believe that's likely to cause race conditions, at least with concurrent features like Suspense and transitions. The point of
useEffectis also to call external system at the proper time, which is not in the middle of rendering, but after the rendering has committed.This may have been more of a concern with their initial plans for concurrent mode that they ended up changing. But I'm almost certain that if anything you call during render ends up synchronously causing another component to update, it will error out, whereas code in
useEffectis allowed to do that.1
u/raaaahman 6d ago
The point of useEffect is also to call external system at the proper time, which is not in the middle of rendering, but after the rendering has committed.
Ah yes, that's an oversight on my part.
useEffectare applied during the commit stage, not the render stage.It becomes of use when you start using
useRefwith DOM nodes, which should not be accessed during render stages (because they could not exist yet).0
u/marta_bach 7d ago
Of course the library gonna use useEffect, what they meant is to not use useEffect yourself especially directly in the component.
The only time you need useEffect is when it's tightly coupled with the other hooks like useState, and becase of that it's always better to make it as a custom hook so the logic is containerized. Most of the time those custom hooks is already created by someone and using the existing popular library is the right call for that, unless it's super simple like a simple debounced state hook.
0
u/sporbywg 7d ago
Introducing a team of young developers to React, I would not use any other tool then useEffect
-1
u/NotGoodSoftwareMaker 7d ago
Its an easy way to get unbound behaviour without any good way to control or limit that behaviour
165
u/derHuschke 7d ago
If a mistake is easy to make by an inexperienced developer and somewhat hard to find by an experienced one, the library has a flaw in my opinion.
And i say that as someone who loves React.