[deckard1]

hooks in general are a huge footgun. You need to place them at the preamble of your function (and not nested). They have to be named with "use" prefix (worth mentioning is React basically commandeered the entire "use" namespace for their own purposes via lint enforcement, which will bite you in the ass eventually), and they are poorly designed.

Take useRef for example. You'd logically expect it to work with useEffect and that would be how you use refs in hooks land. But of course, refs are still a design wart on React (they've been through, what, 4 iterations now and they still can't figure out the interface?!). So of course you need to use useCallback. So what is the point of useRef then? I have no idea. The only use I've found is for "instance" variables. Or maybe onClick callbacks that run later. But now you have a ref that only works in some cases and not others. Yay, "composability"

Browse the React docs and you'll find the caveat-to-design ratio is exceedingly high. On any other project you'd assume this is beta or alpha ware.

[jakelazaroff]

In practice, I don't think the "rules of hooks" [1] are a footgun, especially if you use the eslint rule.

I'm confused about your second paragraph. useRef works perfectly fine for keeping a reference stable so as to avoid triggering useEffect. In fact, that's one of the main tools I use to work around the useEffect dependency array.

[1] https://reactjs.org/docs/hooks-rules.html

[gherkinnn]

useRef can be used to hold a reference to DOM elements, useful for breaking out of Reactland or to hold and mutate values that should not cause a rerender.