feat: Add owning memos to allow memos that re-use the previous value

[pheki]

Currently the memo function:

• Only receives a reference to the previous value when running
• Is required to return an owned value, even if it didn't change

This means that:

• The returned type needs to be allocated and copied one time per source signal change, something that may be very common for slices

This PR implements a Proof Of Concept proposing a new, more primitive, "raw memo", that allows the memo function to receive the previous value as owned, allowing it to be re-used by the memo, like effects (in fact, part of the implementation was taken from there).

"Normal" memos were changed to be implemented by using the raw memo, so there's no need to create a new reactive node. It should be backwards compatible. I haven't checked if there's any performance / binary size impact (benchmarks seems to be broken).

Unfortunately, I don't think the create_slice functions can take advantage of the raw memos with their current signature, but the slice! macro should be able to.

Related discussion: #1034 (reply in thread)

Main use-case: slices

The most prominent use-case is for slices[1][2][3], which can then be implemented to only clone if the value has changed. In [1], being forced to clone on every "source signal" change is actually noted as a major drawback. (1 2 3)

You can use to only clone when the value has changed:

let token = create_raw_memo(move |old_token| {
    state.with(move |state| {
        if let Some(token) = old_token.filter(|old_token| old_token == &state.token) {
            (token, false)
        } else {
            (state.token.clone(), true)
        }
    })
});

You can even re-use the allocation:

let token = create_raw_memo(move |old_token| {
    state.with(move |state| {
        let is_different = old_token.as_ref() != Some(&state.token);
        let mut token = old_token.unwrap_or_else(String::new);

        if is_different {
            token.clone_from(&state.token);
        }
        (token, is_different)
    })
});

[gbj]

This seems good! Might I suggest "owning" memo or something instead of "raw"?

Re: defensively taking the BorrowMut twice: It seems to me that the only situation in which that could happen would be if something during the memo function caused the memo itself to rerun, right? i.e., it would have to do something like setting a signal inside it, that would trigger an effect, that would read from the memo, which will still be marked Check at that point so will rerun?

In this case .take()-ing the value out of the Memo will also cause a panic because Memo::with() always runs the memo function to generate a value if it doesn't exist, so this would still panic.

That is just off the top of my head, I don't have a good test case for either of those situations. In any case it is 100% a bug in the user's code so I wouldn't worry about it too much.

[pheki]

This seems good! Might I suggest "owning" memo or something instead of "raw"?

Yes! A lot better :)

Re: defensively taking the BorrowMut twice: ...

Oh, sorry I didn't make it clear, I was gauging interest so I mostly copied that from the effect implementation (introduced on faa4dc4) and assumed it would be similar for Memos. From you explanation it looks like it's not, so I simplified it.

The test was also mostly adapted from leptos_reactive/tests/slice.rs, but I now updated to match the use-case better.

Also added some docs, I think it's ready for review now!

[pheki]

Hi! Any feedback for this?

[gbj]

So sorry for the delay. This dropped off my radar after I looked at it the last time. It looks great now! Thanks for your work.

[pheki]

ty!!!