Preventing costly clone()'s on unrelated fields when using "create_slice".

[karhu]

I'm basing this off the Global State Management chapter in the Leptos book.

Let's assume I have some global state defined like this, where one field is really costly to clone:

#[derive(Default, Debug, PartialEq)]
struct Costly {
    value: u32,
}

// A hypothetical, costly to clone type. 
impl Clone for Costly {
    fn clone(&self) -> Self {
        log::debug!("Costly.clone() :(");
        Costly{
            value: self.value
        }
    }
}

#[derive(Default, Clone)]
struct GlobalState {
    count: u32,
    costly: Costly,
}

Running the following I see calls to Costly.clone() after each set_count(...):

fn slice_test(cx: Scope) {
    let state = create_rw_signal(cx, GlobalState::default());

    let (count, set_count) = create_slice(
        cx,
        state,
        |state| state.count,
        |state, n| state.count = n,
    );

    let (costly, set_costly) = create_slice(
        cx,
        state,
        |state| state.costly.clone(),
        |state, new_value| state.costly = new_value,
    );

    log::debug!("- creating effect");

    create_effect(cx, move |prev_value| {
        let v = costly().value;
        log::debug!("costly.value changed: {v}");
    });

    log::debug!("- calling set_count(1)");
    set_count(1);
    log::debug!("- calling set_count(2)");
    set_count(2);
    log::debug!("- calling set_count(3)");
    set_count(3);
}

Any way to avoid this?

Perhaps create_slice (or a variant of it) could accept a function that allows to first compare the sliced field against a reference to the memorized value?

pub fn create_slice<T, O>(
  ...
  did_change: impl Fn(&T, &O) -> bool
  ...
)

[gbj]

So, one line is half your Costly::clone() calls: costly().value is the same as costly.get().value and .get() clones. If you don't want to clone, you use .with() like this:

create_effect(cx, move |prev_value| {
  costly.with(|costly| log::debug!("costly.value changed: {}", costly.value));
});

Of course that's only half your situation. The other half is that creating a signal says "hey, this signal owns this data." Creating a slice (which is just a memo) says "hey, this memo also owns this data." The only way to do that is to clone it — we don't (at the moment) have anything like a "memo by reference."

One way forward of course would be to wrap Costly in a type that's cheaper to clone (like an Rc).

Another way is to rewrite so you have something like

create_effect(cx, move |prev_value| {
  state.with(|state| log::debug!("value = {}", state.costly.value));
});

In this case you'll notice Costly is actually never cloned.

The general assumption with the system of signals/memos/effects is that your data is relatively cheap, and side effects are several orders of magnitude more expensive, so the system is optimized for that. If your data are expensive to clone, I'll admit a model that's based on ownership is not quite as good.

---

Here's a version that uses an inner Rc and, as far as I can tell, never runs Costly::clone

#[derive(Clone, Default, Debug, PartialEq)]
struct Costly(Rc<CostlyInner>);

#[derive(Default, Debug, PartialEq)]
struct CostlyInner {
    value: u32,
}

// A hypothetical, costly to clone type.
impl Clone for CostlyInner {
    fn clone(&self) -> Self {
        log!("CostlyInner.clone() :(");
        CostlyInner {
            value: self.value
        }
    }
}

#[derive(Default, Clone)]
struct GlobalState {
    count: u32,
    costly: Costly,
}

[karhu]

Thanks a lot for the detailed answer!

Not using state.with(...) in the effect is indeed an oversight of mine, and eliminates unnecessary clones when the costly field of the state gets updated.

I took your Rc<...> example, and extended it to Rc<RefCell<...>> to allow for mutability of the costly field, this works, and as you said eliminates any costly clones. However (which makes sense) it in turn breaks the memo's capabilities to pick up on changes to the inner value (as equality is checked on the constant reference).

Now, to circle back to my initial question, I think my main gripe is that every time the unrelated sibling field state.count gets updated, a costly clone of state.costly happens, for the sole purpose of equality comparison with the value in the memo. I think this comparison could be done purely using references. I understand that if the two values turn out to be not equal, for the sake of updating the memo, a clone has to happen.

Anyway, I'm still wrapping my head around a) the state management in Leptos and b) the ownership model in Rust, so some or all of this might be off.

[gbj]

I should start by saying that by far the most common solution to this topic is to create two separate signals here, one for each field, as each one then updates individually. This is by far the best way to do what you're trying to do. The "one global state signal" pattern is handy in some cases but not necessarily suited to every case.

I took your Rc<...> example, and extended it to Rc<RefCell<...>> to allow for mutability of the costly field, this works, and as you said eliminates any costly clones. However (which makes sense) it in turn breaks the memo's capabilities to pick up on changes to the inner value (as equality is checked on the constant reference).

I'm not sure I follow, here; can't you just implement PartialEq to check whatever you want to check? I don't think anything's forcing you to use Rc::ptr_eq. Can't remember if this is the default of you default PartialEq here but you can definitely implement it yourself.

Now, to circle back to my initial question, I think my main gripe is that every time the unrelated sibling field state.count gets updated, a costly clone of state.costly happens, for the sole purpose of equality comparison with the value in the memo.

Again just to be clear the best solution here is to store them in two separate signals, so the updates are independent of one another.

I think this comparison could be done purely using references. I understand that if the two values turn out to be not equal, for the sake of updating the memo, a clone has to happen.

This may well be possible, and in fact the memos already do check by reference; it's just that memos are there to memoize on the outputs, not the inputs, ie to cause a reactive notification as infrequently as possible. Like signals (and effects) they always hold a value, which they own. The equality check is done by reference, it's just a reference to the previous value of the memo.

I think you're seeing the tension between "fine grained reactivity" (signals) and global state singletons: we generally want the reactive bits to be as granular as possible. I've seen proposals to do global state with macros that converts struct fields to signals (see eg the leptos_tea library) but I'm not sure an ideal pattern has emerged here.

EDIT TO ADD: I don't think the current create_memo allows it but it's possible to implement a reactive node that takes its previous value as owned (like effect does), not as a reference (like memo does), allowing you to check equality and either return the previous or return a new value without cloning. You'd need to return a bool as well to manually specify whether it has changed or not. It's just that it would require some additional logic which is an across-the-board complexity/binary size increase. I'm not sure it's worth in exchange for supporting this use case.

[karhu]

the most common solution to this topic is to create two separate signals here
Got it, yes that's what I was working with initially, when I saw the state management chapter and was intrigued by the one-global-state-signal pattern. I might go back to my initial approach however 👍

I'm not sure I follow, here; can't you just implement PartialEq to check whatever you want to check? I don't think anything's forcing you to use Rc::ptr_eq. Can't remember if this is the default of you default PartialEq here but you can definitely implement it yourself.

You're probably right. I simply attribute this to my (for now) limited knowledge of everything Rust has to offer.

EDIT TO ADD: (...)
Thanks for those pointers. Perhaps I'll manage to write something like that up in the future 👍

[karhu]

Thanks a lot for the prompt replies, and detailed explanation of trade-offs and alternatives!