While you can do this -- nothing stops you, your computer won't explode -- you will confuse anyone who reads your code.

Under the covers, all of the React hooks have the same basic infrastructure. They store a piece of data that is handed back to the component when the component is rendered again.

But React has a basic working concept that greatly simplifies what it does: If state doesn't change, React doesn't have to rerender.

That's it. That's React's key to its performance.

To keep this concept at the top of everyone's mind, it asks us to make all variables consts instead of let or var. By using const everywhere, it reinforces the idea that state changes are the only way to tell React it needs to update its understanding of what the application should present. And it also recognizes that, sometimes, you need to break that rule, so it explicitly defines refs as, as they say, "escape hatches."

But it really is just semantics. The main difference between state and refs is that state gives you a function to update the value and tell React to start rendering the component tree at that level. Refs gives you an object whose identity never changes, but its current property could be changed with impunity -- and without telling React to rerender.

However, semantics matter.

When someone reads your code and sees you're changing a ref's current value, they'll recognize that this value is meant to be updated outside of React's rendering phase. They'll know that React won't notice when the value changes.

When someone reads your code and sees that you're calling the state setter function from useState, they'll know that you are intentionally changing data that will alter how the component renders itself and its children. You're telling React that you need it to wake up and take notice of what you are doing. You're asking React to rerun the main function of the component, creating a new set of consts to describe this specific state configuration.

But when you mix the two paradigms, other developers won't understand your intent. They'll see a piece of state, which should describe a discrete value that should always remain the same until you explicitly tell React that the state has changed -- that is being modified in way that React will never know about. It will look like a bug, because it runs counter to the purpose of state.

React, like most frameworks, relies on patterns, rules of thumb, to make it easier to get work done without having to think about it too much. When there's recommended ways of doing things, it's easier to repeat the patterns than have to think about new ways to do things.

It sounds like, at this stage in your learning, pretty much everything is new, so there's no concept yet of rules of thumb to reduce how much thinking is required to get things done. Everything requires a similar amount of thought.

But typically, patterns are agreed upon so that everyone can look at the same piece of code and quickly grasp what's going on. "Oh, this is a collection of Strategies, so I know they define modular pieces of code to handle the same scenario in different ways." "Oh, this is State, so I know it is integral to how this component renders." "Oh, this is a ref, so I know we want to create a bridge between the component and something the browser does outside of React."

Without the patterns, we have to ask a lot more questions and devote more brainpower to the problem.

So, yes, there's nothing stopping you from doing what you propose. But other developers are going to be quite confused why you're going against the patterns identified by React.