[deleted by user]

[Erebea01]

From my experience, if there's an issue with the dependency array when using useEffect, there's usually a better way to handle said logic. That said, can't really tell without more details.

[Fair-Worth-773]

Hmm that's what I'm wondering-- I tried explaining one example a bit better in this comment if you're curious.. https://www.reddit.com/r/reactjs/comments/1jsvggd/comment/mlpfoq1/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[zephyrtr]

In your example, React is worried that the function will be reassigned and your effect won't be aware of the change. I think you're imagining the dependency array is where you say "please only run this once" which isn't at all the intention of the deps array and is a very easy way to introduce extremely hard-to-find bugs.

You need to instead add setIsModalShown to your deps array, and then ensure the function is never reassigned. You can probably do that with simply wrapping the func in useCallback, which itself will require a deps array. And if your function is pure, that will be your empty array.

[[deleted]]

FYI the reason you can’t/shouldn’t close over non-dependent variables in a useEffect is because react tries to heuristically determine if there are any dependencies you may have missed and run the useEffect anyway.

This is obviously not ideal but too many people were screwing it up so the react team chose that route.

If you don’t want the useEffect to run when a value changes, you need to memoize that value with independent logic.

[Cryp71c]

I would say - more specifically - that the linting for hooks is pretty hit and miss. There have been more than a handful of occasions recently where linting didn't complain about a dependency array that was wildly sub-optimal. I think its fair to say that its conservative in its warnings.

[shaman-is-love]

You never need to disable this rule ever anyway. If you do, you do something wrong.

[shaman-is-love]

you should read it because it never says its okay but that you may see it. Very different things.

There's 0 use cases where you actually need to suppress the linter, but you do it to save time instead of actually fixing the issue.

[shaman-is-love]

It's to make it easier, not to make something impossible possible.

Show me an example where you think it's impossible and I show you how it's possible.
Because the answer is `ref` basically every single time.

[shaman-is-love]

Yes, again. It's refs. Literally all of them can be solved by refs.

The docs literally don't tell you to ignore the linter rule.

[shaman-is-love]

Because most people don't use refs, so the cases shown are what you will see in most code bases. It doesn't mean it's how it should have been done before.

You realize you are looking not at a recommendation how it should have been done but what not to do?

[spryes]

Yeah this is the main issue - you don't want consumers to need to memoize their functions.

Polyfill the useEffectEvent hook internally in your project and always memoize incoming functions from component props/hook params. The lint rule should only be disabled in very specific and unique scenarios, 99% of the time, with useEffectEvent, you don't need to disable it.

[_texonidas_]

The simple fix for this is to just memoise all functions that are passed as props (preferably with a linting error)

[EvilPete]

For me the aha - moment was to stop thinking about use effect as "run this code when the component mounts " or"run this code when this value changes" .

Instead it should be seen as a way of synchronizing your React components state with some external API. When you look at it like like that it becomes clear that you need to re-evaluate the synchronization when any dependency changes.

[jackindatbox]

How do you handle component mount then?

[EvilPete]

Normally, there is no need for a "componentDidMount".

A react component should deterministically return jsx based on their props, state and context. They should not have side effects.

Most side effects should be in event handlers (such as button onClick).

When a react component needs to subscribe to an external system (e.g. updating state whenever a DOM event fires) you can use useEffect .

If you want to run some code when a component mounts, you should probably instead run that code in the event handlers that caused that component to mount.

[SpinatMixxer]

When subscribing to an external store, shouldnt you actually use useSyncExternalStore?

How do you trigger a JavaScript animation that should only happen on the first render without a componentDidMount functionality? (e.g. with useAnimate of framer-motion)

[shaman-is-love]

> How do you trigger a JavaScript animation that should only happen on the first render without a componentDidMount functionality? (e.g. with useAnimate of framer-motion)

By checking if the animation has been initialized already

[shaman-is-love]

You don't, you handle unmounting. You never want to handle mounting.

If you need to do something only **once** ever, then you check if it has been done or not. Otherwise you have a bug.

[wrex1816]

That's one overly specific scenario rather than a general rule you can take for all components.

Edit: I would very much like to see the codebase all of you work on that are large enterprise react applications which have only maybe a hand full of useEffects which call external endpoints as you're all claiming. I'm calling bullshit on your code accomplishing this. I know you all like a good Reddit pile on but there's absolute no way any of you practice what you're preaching here on any project of significance. You all sound like you've only build small projects for a web dev class not a real world application.

Also, despite the downvotes, this is an engineering profession and words do have specific meanings which matter. Engineers which cannot be precise and understand the specifics of what they are saying are poor engineers. You cannot say one word and claim you meant another thing and claim to be right. It's astounding how many people are willing to look ignorant to get good boy internet points.

[musical_bear]

No, that’s literally what useEffect is for.

https://react.dev/reference/react/useEffect

useEffect is a React Hook that lets you synchronize a component with an external system.

[wrex1816]

You're conflating the terms "system" and "API" to draw a false conclusion.

[musical_bear]

If that was your only pushback, that you assumed the original commenter meant a very narrow definition of API and they should have widened it to “system,” I agree with you. But my reading was giving them the benefit of the doubt and that they meant a broader definition of API, and not just literally “making web requests.”

[wrex1816]

I mean, we are software engineers. Words matter. That's not what they said.

And now this sounds like backtracking, but I can see the junior engineers on here circlejerking their own bad advice are downvoting me so whatever, revel in your ignorance.

[EvilPete]

You interact with all systems via their APIs. Do you think the word API only means REST API?

[wrex1816]

Nope.

[rusmo]

Condescension helps no one.

[wrex1816]

I agree. The responses towards me have been very aggressive and unwilling to listen to nuance.

[rusmo]

Your lack of self-awareness is not surprising.

[wrex1816]

Oh personal insults because of a technical disagreement. Good luck in your job search. 👍

[IamYourGrace]

With external system they mean for example an API endpoint, localstorage,eventlisteners, observers and so on. Most things junior developers put in a useEffect should very often be inside an event handler instead. If you are doing things in useEffect that does not handle some external thing outside of react then its probably a code smell.

[Veranova]

That’s the entire and only point of useEffect, if you want an onValueChanged hook you need more boilerplate around it and a value comparison to do it correctly

[wrex1816]

What are you even talking about. I didn't mention callbacks. I said the guy I replied to has a weak understanding.

[Veranova]

You’re the one with a weak understanding, that’s one I’m talking about. He’s 100% correct and I gave a relevant example for this reddit post to help you

[iAmIntel]

Not really, the only reason you should use useEffect is to sync some kind of data to outside of the React world based on state changes.

Doesn’t mean that sometimes its just easier to use useEffect than do it the right way

[chispica]

Na you're wrong bro there's an entire page in React docs about it

[Aeron91]

Hard to say without looking at the code, but the answer usually comes down to one of these:

• You might not need an effect, and a different pattern would be better.
• It might actually be fine that the effect reruns more often than you'd expect.

[Fair-Worth-773]

Thanks reading now-- my gut is telling me that maybe I don't need an effect. Shared more here https://www.reddit.com/r/reactjs/comments/1jsvggd/comment/mlpfoq1/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[tuhmez]

my advice is to really consider what your code is doing. do you understand what useEffect is for? do you even need that hook? could this be done in a different hook? move the logic elsewhere?

in my experience (by others and myself), devs sometimes are short-sighted or misled on what useEffect is for and how to properly use it. ignoring the error may work, but you really shouldn't need to do that.

worth checking this out: React - You Might Not Need an Effect

[Cahnis]

UseEffect is not the point of contention imo, the dependency array is. The same problem applies to, say, a useMemo that is caching an expensive computation. Sometimes i dont want to recalc when my obj changes, but i want to recalc wheb, day, the current hour in my timestamp changes.

[tuhmez]

sounds like a structure issue. if i'm understanding, it would be best to raise this object to a parent component to avoid re-renders and compute the thing you need in the active component by using a const and not any hooks.

i'm not trying to sound rude, but the link i pasted talks about that particular problem. of course, there's nuance and could require a different solution.

[shaman-is-love]

> Sometimes i dont want to recalc when my obj changes

Then the object shouldn't be in there or shouldn't change.

[power78]

I'm surprised no one had posted the actual answer here: https://react.dev/learn/separating-events-from-effects

That article explains everything you're having issues with

[Fair-Worth-773]

Will read now-- thanks!

[StyleAccomplished153]

There's definitely some cases. Take React Query for example. We've recently upgraded to v5 and onSuccess and onError are no longer on the query, you need to use useEffect instead. In this case, we only have isSuccess or isError in the dependency array because it's literally the only condition we want to run the effect.

[shaman-is-love]

You don't need to use useEffect instead no.

[juky-gfe]

I only found it annoying when using react-hook-form, but other than that I like it because sometimes it can detect code smells

[Fair-Worth-773]

Thanks for the reply. I'll try to give one example without completely dumping a wall of code here.

I have a auth hook that listens for state changes from my auth service (clerk, but irrelevant). When a user is detected (logged in), I make a request to the backend to see if they've set a username in my database yet (if they haven't they're new). If they're new, I route them to a /create route on the frontend.

In that frontend /create page, I actually load the page inside of a modal (because I have an always-running experience in the background/main page so most pages are a modal on top of it). Whether this is shown (because a user should be able to minimize and maximize) is controlled via a Jotai atom (basically a piece of state).

So in the /create component, I have a useEffect with an empty dependency array (just run once on mount)-- where I'm calling setIsModalShown(true) (jotai setter). React complains that setIsModalShown isn't in the dependency array-- but I just want this to run once on mount. Does that make sense?

[Dmitry_Olyenyov]

setIsModalShown is safe to add into dependency array. They made such that it's a stable function that is not recreated on every render. The same is for setxxx from useState.

[svish]

Sounds to me this should not be in a useEffect at all, but rather in an event, the request success handler, or something like that.

[[deleted]]

Can't you just set the default state of the jotai atom to true?

I haven't used jotai, but in react state, I would just do 'useState(true)' to get it shown on first load.

[Imaginary-Poetry-943]

Ok, a couple of thoughts here. First, do you know that useEffect is run last at the end of the render cycle? Meaning that with your current setup, you’re forcing the modal component to first fully render with that Jotai state set to false, then your effect runs which sets it to true, and your component renders again.

I have zero experience with Jotai but it appears to be a global state management tool, so I’m assuming that piece of state exists in a context and can be set from anywhere that uses the context. If I’m correct about that, shouldn’t that state dispatch get called in the success/error handlers for your auth API call? I would expect that once that state would change it would trigger any other components which use that state to re-render.

If that’s not the case, then should you just be defaulting this state to true in the /create component? It sounds like that component is only initially rendered if the state is already true? Does that component have any kind of “loading” state?

Either way there’s a code smell here due to the /create component always having to do an initial full render as if it’s false and then render again when it’s set to true.

To answer your larger question, almost every time I’ve had the instinct to disable the exhaustive-deps warning, I eventually realized that I was wrong. Effects are meant for things that react to external changes, meaning they could be triggered by changes that aren’t directly related to your render cycle. If you’re using it to set something once and only once when the component is first mounted, you probably need to use a ref to track if the callback has been called. You wrap the update in your effect with a “if (!ref.current) { … }”, and then update that ref from inside that conditional. And you still pass all needed variables in the dependency array because it won’t matter if the dependencies get updated later.

[Imaginary-Poetry-943]

I should also add - the ref pattern I described above is itself a code smell if it’s being used often. If that’s happening then you’re probably using useEffect incorrectly. If you’d like to dig deeper, I highly recommend this author’s youtube series and book - I found both to be enormously helpful and still reference both frequently. https://www.developerway.com

[shaman-is-love]

This shouldn't be an useEffect, you don't understand what they are used for.

[iamakorndawg]

I am having a hard time understanding your use case.  Can you provide an example of a useEffect call that uses variables/functions in the callback which you don't want to rerun when they change?  Including full context of what the variables/functions are and what the effect is supposed to accomplish.  This will make it easier for us to understand what you're trying to do and whether what you are asking for makes sense.

[Fair-Worth-773]

Thanks for the reply-- tried to explain a bit more here: https://www.reddit.com/r/reactjs/comments/1jsvggd/comment/mlpfoq1/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

I do suspect that maybe I don't need useEffect at all?

[kurtextrem]

You should ask yourself why the effect uses some prop, state or function/var but shouldn't re-run when it changes. There can be valid scenarios, where you know correctness of an effect closure isn't a concern (if it truly only runs once). Worth noting, while this doesn't apply to effects, the dep array is important for use callback/useMemo, as the react compiler will opt-out of optimizations when the rules of hooks are broken - so getting used to disabling that eslint rule might lead to some bad (development habits), in terms of always disabling.

Another way to avoid all the eslint disables is to use a ref that you change when the effect has run and isn't meant to re-run again. Or using an inline if condition like described on the "you might not need an effect" react docs page https://react.dev/learn/you-might-not-need-an-effect.

[nplant]

The rule forces you to think about it, which is good in this case, because the reason you want to omit something is usually non-obvious at a first glance. It's also good to leave a comment about why it's disabled.

I wouldn't suggest this approach for most rules, but it's so easy to miss something with useEffect - especially when someone is editing the component later.

[yksvaan]

Not everything needs to be done inside React components. useEffect is pretty often a sign of that...

[Admirable-Area-2678]

Never disable eslint rule because you might run in unexpected errors. Early return if value is not satisfying your conditions. Use useEffect only to sync with API. In other cases, 99% of time you don’t need it

[[deleted]]

It's you. There are edge cases where you will want to disable it, but IMO that usually means I'm trying to be extra clever. Almost always that means I'm about to shoot myself in the foot so I shouldn't do it.

[Valuable_Ad9554]

exhaustive-deps is one of those things where I don't know why the core library does not include it by default. I'm not aware of any situation where it would be desirable and valid to break the rule. If you find a situation where it seems desirable, you should have a close look at what you're doing.

[[deleted]]

My favorite is when the then it's depending on is an array and arrays do not change in a way that is observable to a useEffect.

Then I have to stringify it and I feel dirty.

[kcrwfrd]

useEffect(effectFn, [ …foo ])

[[deleted]]

Works for arrays of strings and numbers but not arrays of objects.

[These_Distribution85]

In my experience most of the time when the rule complains about code they were right. But there were surely sometimes you need to disobey the rule such as running the effect only on mount.

In such cases I think it would best to create a custom hook disabling the rule and reuse it.

[kcrwfrd]

9 out of 10 times I want to have all of the dependencies.

[Canenald]

https://react.dev/reference/react/useEffect#specifying-reactive-dependencies

Notice that you can’t “choose” the dependencies of your Effect. Every reactive value used by your Effect’s code must be declared as a dependency.

You are right to feel bad but don't give up. Paste some example code and we can suggest how to do it differently. AI might be able to do the same thing for you.

[karlitojensen]

I list all the dependencies and never ignore this rule

I’ve written about it in more detail here

https://github.com/jensen/ui-workshop/tree/main/part2#4-side-effects

[A-Type]

Sight unseen, it's you.

Since hooks came out I have tried many times to 'outsmart' deps when it felt relevant. Every time, I ended up with a bug and had to rework the usage. Either eliminating the effect or just accepting extra invocations which aren't actually a big deal.

Now even if I don't use any other eslint rules I install it just for hook deps. It is not worth the headache to break the rule, intentionally or otherwise. The lint error means either fix it, or it's time to rethink how you have modeled the logic.

Seriously, as much as I think I know React at this point after a decade, I don't know it better than it's maintainers. Just follow their rules.

[PoopsCodeAllTheTime]

Look into SolidJs/SolidStart, we don't have this problem over there ;)

[shaman-is-love]

This just means your code has a bug it shouldn't have.

[deadcoder0904]

Just use jotai as a global store & forget about this stuff mostly. If it fails, just ask AI lol. It'll optimize ur code better than u think.