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

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.