If you're not aware of that, it is very tempting to use `useRef`, which is what I have often seen. Before hooks, we did not have the temptingly-named footgun `useRef` for this scenario (although we did have other footguns for other scenarios, and overall I love hooks).
Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune.
Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated.
Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes?
(I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)
I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable.
I'm not sure if there is a less confusing way of doing it, but it's damn confusing.
If you're not aware of that, it is very tempting to use `useRef`, which is what I have often seen. Before hooks, we did not have the temptingly-named footgun `useRef` for this scenario (although we did have other footguns for other scenarios, and overall I love hooks).