What is the equivalent of useRef in Leptos?

[bluenote10]

Trying to solve this question I started to wonder how to store mutable component-scoped data that is not really a signal, in this case a ResizeObserver instance. In React this would be a use case of useRef I guess. Since we are using move closures everywhere in Leptos it isn't just possible to instantiate something like a ResizeObserver directly in the component function, because it would be moved away.

[gbj]

So it's important to start with the question, "Why on earth does React have useRef anyway?" In other words, why useRef instead of a normal variable?

I'm not a React expert by any means, by as I understand it, the reason React needs useRef is that the body of the component function runs over and over again whenever state is changed. This means that anything stored in a normal let or const variable inside the body of the component function is created again and again. useRef exists to tell React "no, don't create this object again, actually looked in your collection of stored stable references and use the thing you created the first time you rendered this function."

Leptos doesn't have this problem: The body of the component function only runs once, so all the normal rules of Rust ownership and borrowing apply exactly as you'd expect. However, it does still need some kind of wrapper because of the interaction between Rust's ownership and movement rules and the fact that any closures that will be shipped to JavaScript or stored in the reactive system need to be 'static (i.e., need to own all their contents).

If you need to share ownership of an object across two closures or between a closure and the world outside the closure, etc., this means you'd typically wrap it in an Rc, clone it, and move it into both places.

Leptos also provides a store_value function, which is probably what you're really asking for here. This stores some object in a Copy wrapper that behaves just a like a signal does, but is non-reactive. This gives you the convenience of being able to move it into closures etc. very easy, and follows all the same rules as a signal (i.e., it's disposed of when the scope is disposed, etc.) In this sense if create_signal is like useState, store_value is like useRef — follows all the same rules but isn't reactive.

Per your comment in the other question, to run something when the component is removed you can use the on_cleanup function.

[bluenote10]

Thanks a lot for the explanation! It is indeed an interesting question why React needs useRef, and it makes perfect sense that a truly reactive component function doesn't really need it. Having followed the development of s-js and solid-js this all sounds familiar.

What still causes me some headaches is the semantics of on_cleanup. I expected that I can move data from the component function scope into that closure, and every time the component gets unmounted the closure runs and can do its thing to clean up all data of that component instance. However, this doesn't seem to be the case: I've placed a log! statement in my on_cleanup callback and it looks like it never runs despite repeated mounting/unmounting the component many times (leading to memory leaks correspondingly). According to the docs this might be because the cleanup is actually tied to the reactive scope, not the component itself. Since I'm just using the plain root scope, and I never dispose of it, the cleanup will probably never run. This feels a bit worrying -- doesn't it mean that without manually creating child scopes (which I don't understand yet) everything is prone to memory leaks?

I vaguely remember from solid-js that e.g. effects could always return another callback, which serves as the corresponding cleanup side effect of that particular effect. If I remember correctly it was guaranteed that these effects run on the component level, making cleanup on unmount very natural. Would it make sense to offer a similar higher-level cleanup functionality?

EDIT: Perhaps I just ran into #802?

[gbj]

I vaguely remember from solid-js that e.g. effects could always return another callback, which serves as the corresponding cleanup side effect of that particular effect.

Just to nitpick: IIRC returning callbacks is actually React's way of handling clean-ups, Solid runs its onCleanup functions every time an effect re-runs.

What still causes me some headaches is the semantics of on_cleanup. I expected that I can move data from the component function scope into that closure, and every time the component gets unmounted the closure runs and can do its thing to clean up all data of that component instance. However, this doesn't seem to be the case: I've placed a log! statement in my on_cleanup callback and it looks like it never runs despite repeated mounting/unmounting the component many times (leading to memory leaks correspondingly). According to the docs this might be because the cleanup is actually tied to the reactive scope, not the component itself. Since I'm just using the plain root scope, and I never dispose of it, the cleanup will probably never run. This feels a bit worrying -- doesn't it mean that without manually creating child scopes (which I don't understand yet) everything is prone to memory leaks?

If I remember correctly it was guaranteed that these effects run on the component level, making cleanup on unmount very natural. Would it make sense to offer a similar higher-level cleanup functionality?

EDIT: Perhaps I just ran into #802?

Ding ding ding! This is #802. Our built-in control flow components (<Show/>, <For/>, and the router) should correctly handle on_cleanup but otherwise you're correct that manual child scope creation and disposal (gross) is the issue here.

But I was thinking last night and realized that the reason Solid doesn't have this issue is that rather than nested Scopes, like we have, Solid associates these cleanups with effects — so that every time the effect runs to mount or un-mount that component, the cleanup runs. This makes perfect sense and actually helps me understand why that was the right decision. This would also avoid some of the API-breaking downside of #802/#803, so — thank you for this discussion, this has been very helpful!