In a React component, an effect re-runs on every render because it depends on a callback prop that the parent recreates each time. A teammate stops the churn by adding // eslint-disable-next-line react-hooks/exhaustive-deps and dropping the callback from the dependency array. Why is that the wrong fix, and what would you do instead?

## What the rule is actually asserting `react-hooks/exhaustive-deps` performs a static read of the effect body and collects every reactive value it references — props, state, and anything computed from them inside the component. Its claim is narrow and checkable: *this list is what the effect reads, so this list is what must be in the array*. It is not guessing at intent and it is not a performance heuristic. When it warns, one of two things is true: the array is wrong, or the code is shaped in a way that makes the honest array unusable. Suppressing the warning resolves neither. It only removes React's ability to re-synchronize the effect when that value changes. ## Why the suppression makes things worse, not merely equal Before the suppression the failure was visible: the effect ran on every render. Wasteful, maybe noisy, but discoverable in a profiler and reproducible on demand. After the suppression the effect runs once and then holds the callback instance from that run. Suppose the parent's callback closes over a `selectedId` that changes later. The effect happily invokes the old function, which writes to the old id. Nothing throws, nothing warns, and the bug surfaces as an inconsistency reported by a user days later — "it saved to the wrong record". That is a strictly worse failure mode: same defect, no signal. The general principle worth saying out loud: a dependency array is a declaration, and the lint rule verifies the declaration against the code. Silencing the verifier does not change what the code depends on. ## Find the real cause first Ask which dependency is unstable and why. Almost always the answer is that something is being recreated every render: - a function expression or arrow defined in the parent's body and passed down, - an object or array literal built inline in JSX, - a value returned unmemoized from a custom hook, - a context value object constructed fresh in a provider. Once you name the source, the fix is usually at the source and it is small. ## The fixes, in the order I would try them **Move the work inside the effect.** If the function exists only to serve the effect, define it inside the effect body. It stops being a dependency, and the array shrinks to the values it genuinely reads. ```js useEffect(() => { function report(result) { /* ... */ } const conn = connect(roomId, report); return () => conn.close(); }, [roomId]); ``` **Stabilize the identity where the value is created.** If the callback must be a prop, the parent wraps it in `useCallback` with its own honest dependency list. Then the child's effect can list it truthfully and it will not churn. **Use a functional state updater.** When the only reason a dependency exists is that the effect computes new state from current state, `setX(prev => ...)` removes the read entirely and the dependency disappears legitimately. **Keep the latest value in a ref, deliberately.** When an effect must maintain a long-lived resource — a socket, an interval, an observer — and merely needs to call the newest callback when something happens, writing the callback into a ref and calling `ref.current(...)` is a recognized pattern. It keeps the resource alive across changes, at the cost of making the effect explicitly non-reactive to that value. Do this in the open, with a comment explaining why the effect must not re-synchronize, rather than by hiding the dependency. ## Is suppression ever defensible? Sparingly, and it should look nothing like the example above. A genuine mount-only imperative bootstrap — logging an app-open event, initializing a third-party widget exactly once — sometimes cannot be expressed through the dependency array. When you accept a suppression, three things make it survivable: it is `eslint-disable-next-line` scoped to that one array (never a file-level disable), it carries a comment explaining what is intentionally not reactive, and the values it hides are ones you can argue will never meaningfully change. "I could not get rid of the loop" is not that argument. ## How to say this in an interview Lead with the diagnosis rather than the rule: the effect re-runs because a prop's identity is unstable, and the identity should be fixed where the value is created. Then explain what the suppression trades away — a visible, reproducible churn replaced by an invisible staleness bug — and name the concrete fixes. Finishing with the narrow, commented case where suppression is acceptable shows judgment rather than dogma, which is exactly what the question is probing at senior level.