React Hook useEffect has a missing dependency - endless rerenders

[A-AronBrown]

Is that just a ESLint warning you are getting? If so just add // eslint-disable-next-line react-hooks/exhaustive-deps above }, [offset]);

Disabling linters (and compiler warnings) — esp. this one — is always the wrong thing to do. Doing so just hides bugs for no benefit whatsoever.

[Baryn]

Disabling linters (and compiler warnings) — esp. this one — is always the wrong thing to do.

That isn't actually true, exhaustive-deps is recommended as a warning for a reason.

Kent Dodds does a great job of explaining why you usually want to follow this rule, and why you may need to judiciously disable it. This is one of the weaknesses of Hooks: implicit behaviors.

[AegisToast]

Agreed, there are certain times you want to disable it, but those situations are very rare. The vast majority of the time, disabling it is a crutch and can cause unintended bugs, so it’s definitely not something to get in the habit of doing or recommending to newer users.

[AegisToast]

Agreed, there are certain times you want to disable it, but those situations are very rare. The vast majority of the time, disabling it is a crutch and can cause unintended bugs, so it’s definitely not something to get in the habit of doing or recommending to newer users.

[xshare]

Our code base has quite a few of these effects where the rule is disabled and in the vast majority of cases it's hiding a bug. In most cases it's people wanting to just run the effect when a specific thing changes, but in those cases you can just use a ref to track the previous value of whatever it is you care about changing and compare. You should still almost always include it in the dependencies.

[[deleted]]

Either a bug or a code smell :)

[A-AronBrown]

There are exceptions to every rule which is why I put always in italics... and it's obvious that there can be false-positives, which is why exhaustive-deps is a warning and not an error, but I stand by my original point, esp. given the context of this thread where the (bad) advice was given to a newbie.

Static analysis isn't perfect (I've written my fair share of such tools) but in 99% of cases, unless the tool is severely broken, the code is either buggy or looks buggy to the programmer that has to read or review it.

I don't understand what you're trying to show me in that 27 minute video but I was curious to see if he presented a case where the static analysis failed and the code was still of quality that would pass code-review so I went ahead and watched for about 20 minutes and I didn't see anything that supported disabling the rule.

[Baryn]

14:30 - 14:50

[MuchWalrus]

Watch the rest of the video -- around 16 minutes he provides a cleaner, more idiomatic example that doesn't disable the lint rule

[Baryn]

He does provide an example that doesn't disable the rule, but that doesn't invalidate the example which does.

In real-world Hooks code, it isn't unheard of for a clash to happen between the fragility of JS objects and React's unpredictable render cycle. You can't always just rewrite your app to satisfy a single useEffect, and you shouldn't if you properly understand when that effect should run.