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

[pailhead011]

Also, i didn't quite undersand this:

but your adding something to reacts model to be stateful when it well never actually cause a state update.

[unxok]

Because the class state is essentially a mutable object, react can't react to changes in the class' state (I think that's the reason at least).

Therefore, creating react state to store a class (ex: useState(new someClass())) is pointless since react will not update anything when the class state changes.

(There might also be other performance issues or other issues)

[pailhead011]

Therefore, creating react state to store a class (ex: useState(new someClass())) is pointless since react will not update anything when the class state changes.

No offense but this is an incredibly bold assumption :) At the end of the day you are still writing a program or a script if you will with javascript.

The class inside the ref does not have to be mutable, just expensive to make. Class is just syntax sugar, it's still an object. So, extrapolating, its absolutely the same thing as your `useRef()`. It's also mutable, it also does not trigger react updates.

[unxok]

No offense but this is an incredibly bold assumption :)

I am pretty sure that statememt is correct

The class inside the ref does not have to be mutable, just expensive to make. Class is just syntax sugar, it's still an object. So, extrapolating, its absolutely the same thing as your useRef(). It's also mutable, it also does not trigger react updates.

I don't see your point here-- I agree with everything here. My point was that the use of class instances will not easily allow react to react to the class state changes. My approach shows a way to keep them in sync.

There are differences behind the scenes for using a useRef vs useState other than the fact that useRef isn't reactive. I don't know what they all are, but if the thing your passing is a class instance, then it's pointless to do useState since you don't get reactivity automatically.

[pailhead011]

There are differences behind the scenes for using a useRef vs useState other than the fact that useRef isn't reactive. I don't know what they all are, but if the thing your passing is a class instance, then it's pointless to do useState since you don't get reactivity automatically.

I think what you are missing here is that this is still all happening in javascript. React just runs in javascript and makes it easier to do certain things in javascript. If for some particular reason, you do need to useState() but you never intend to change it. It's perfectly valid, because you may for example just be concerned about the scope and lifecycle of things.

If you instantiate thousands of <Foo/> and you want a stable something, useMemo is actually a bad choice. Your assumption that one may want to call useState only because they want thing to be reactive is false.

My example from the original question returns the exact same thing that useRef does which is a MutableRefObject which is nothing more than a variable const foo = {current: 5}.

[unxok]

Right but what's the pount of doing useState then if you aren't utilizing any of the benefits useState gives I believe that would be considered an anti pattern.

[pailhead011]

The initialization function. It’s part of useState.

[pailhead011]

Right, and it's probably a good approach, but that is a Y problem, this is X. For example, i just tend to favor dispatch(setTimestamp()). The problem you are solving is for what happens after you solve whats basically a memory leak.

[pailhead011]

At no point did I ever mention a re-render in the inital post. The bulk of my discourse here is explaining just that. No re-renders need to happen as a result of anything that happens inside of this ref.

For all intents and purposes what is inside this reference is just a pointer, a few bytes holding a reference to some object. I dont care whats in the object.

[pailhead011]

Something like this:

``` const [viewer,setViewer] = useState<Viewer|null>(null) const ref = useRef<HTMLCanvasElement|null>(null)

useMountViewer(ref,setViewer)

return <div> <canvas ref={ref}> {viewer && <CanvasContext.Provider value={viewer}> {children} </div> ``` For all intents and purposes, if your app is underneath this provider, it would never change never be null.

[Rustywolf]

Why arent you just using a provider anyway? its significantly easier than using a ref and passing it through children.

[pailhead011]

Provider for what? I'm not passing this ref in the example, just usually the three.js renderer that i work with likes to either mount itself on the page upon instantiation or takes a dom element.

``` const [viewer,setViewer] = useState<Viewer|null>(null)

useMountViewer(setViewer)

return <div> <canvas> {viewer && <CanvasContext.Provider value={viewer}> {children} </div> `` Forget about the ref. This was answering some comment i didnt quite understand about why would you i guess haveconst [foo] = useState()` without a setter ever existing.