The useEffect dependency array defines the values for which you want the effect function to trigger any time those values change.
It is not always the case that you want an effect to trigger for every value used inside of an effect. Sometimes you only want an effect to run once (i.e. the empty array passed as deps). Sometimes a value changes too frequently to list as a dependency: https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...
Not to mention some of those variables auto-included are pointers to arrays/objects which won't trigger a change if their contents change, so you actually need a hash (or something more clever and specific) of the contents which should trigger a re-render... e.g. rendering the contents of a list sorting would want to listen to the 'sortBy' state rather than the list contents - even if the component wouldn't have used sortBy otherwise...
(this is all just bringing back painful memories - hopefully which aren't the same problem now? - from a project where I was the only developer on the team learning these intricacies, and having to figure out why everyone was getting infinite render loops or static components in weird situations, even as they blindly followed their linter useEffect suggestions... Needless to say, our code lucked ugly as hell after all this was done "right".
In retrospect I might have done all this at the app state level, pre-processing the inputs for each component with something like a 'usesEffect' boolean and a 'changeTriggers' array, then some generalized auto-reader util functions to parse that with default boilerplate behavior, just to get that stuff out of my frontend components... I suspect that would only move the problem up, but at least then you're just modifying json instead of also muddying all your templates. Subcomponent wrapping or something like that could work too. Idk. Gross stuff. Was unfortunately necessary with a ton of asyncronous calls and big data lists.
Maybe DB/API-fetched State > Frontend Parser & useEffect/Async Logic > Actual JSX Component Rendering separation...? (so - Model Controller View?) If it wasn't all already inherited legacy code mighta structured it like that more, instead of just rawdogging API results in JSX.
The documentation you linked itself says to structure your code such that you are not taking dependencies inappropriately, not to omit bona fide dependencies from the dependencies array:
Specifying [count] as a list of dependencies would fix the bug, but would cause the interval to be reset on every change. Effectively, each setInterval would get one chance to execute before being cleared (similar to a setTimeout.) That may not be desirable. To fix this, we can use the functional update form of setState. It lets us specify how the state needs to change without referencing the current state:
It is not always the case that you want an effect to trigger for every value used inside of an effect. Sometimes you only want an effect to run once (i.e. the empty array passed as deps). Sometimes a value changes too frequently to list as a dependency: https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...