On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default.
In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref.
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.
But it's a pretty straightforward rule once you know it right?
This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs.
Once you know refs updates won't re-render, you won't make this mistake.
I don't understand why "a thing you need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn.
> but most people think of refs as...
This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.
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"?)
There's always need for escape hatches and maybe I'm missing your use case, but in the context of a discussion about how hooks are more complicated than classes, what were you doing before with refs to solve your "re-render" on change scenario?
Your example was likely contrived, but modifying innerHTML should be replaced by putting whatever in state and simply rendering it. And use state for dependencies where you want to re-run on change. Refs are just another way to keep state but not have it affect render cycle.
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).
On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default.
In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref.
[1] https://github.com/facebook/react/issues/14387#issuecomment-...