[ElKrist]

I tried to address your type of reaction in my "If your initial reaction is(...)" sentence, but that failed.

The point is not that this code is good or bad. It's that it is possible to write such hard to predict code.

Remember this is a stripped down version of some code running in production.

Now to address your specific points anyway: "There's no reason to reset again": in the non-stripped down version, the hooks rely on a third hook (let's call it "useToken") and needs to react accordingly to this change of token to fetch new data

"I'm not sure why you'd even consider putting the functions in the dependency array for the useEffect in usePets.": unfortunately react-hooks/exhaustive-deps is here to warn you. You can disable or ignore it but I guess you expose yourself to a real missing dependency? Genuinely very keen to hear if you use this rule in your projects and what you do in such cases (where you use a function in the useEffect but do not want to re-run the effect each time this fn changes). To me it's such a weird/unnatural thing to list functions as dependencies because almost all the time functions do not change.

[pcthrowaway]

Ahh well the setter functions are excepted for the exhausted-deps rule, which is why I hadn't encountered it: https://legacy.reactjs.org/docs/hooks-faq.html#is-it-safe-to...

> (The identity of the setCount function is guaranteed to be stable so it’s safe to omit.)

Maybe in JS it still warns in your example because setData is passed in from calling useResource, but at least with Typescript I'm pretty sure eslint infers this