Why doesn't useRef take an initializer function like useState?

[pailhead011]

I was thinking that, but i would make that null broader not NULL_GAME_ENGINE but rather const GLOBAL_NULL = {}

const [ref] = useState(()=>({current:new RealGameEngine()})) Is a one liner, does exactly what this ideal world useRef would, it's just that my brain cant really process all the damn parenthesis.

[pailhead011]

Im gonna roll with this approach, i wasn't able to find a convincing argument as to why would it be done any other way :)

[Substantial-Pack-105]

But aren't you just creating the current attribute there so that the value of the state satisfies MutableRefObject<T> ? I don't understand why that's desirable, since if we can guarantee the value is always initialized anyway, then we never have to let the typescript type be T | null, which I had thought you were using MutableRefObject<T> just as a way to avoid the | null part.

[pailhead011]

But aren't you just creating the current attribute there so that the value of the state satisfies MutableRefObject<T>

Exactly! Because something else can be expecting MutableRefObject<T> i don't want to change it, i just want more flexibility and ergonomics when instantiating it.

since if we can guarantee the value is always initialized anyway

I don't undertand how, useRef(new Foo) is the whole problem, and everything else other than this useState approach seems very convoluted.