Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use_memo does not properly diff inputs and drops updates #2416

Open
1 of 3 tasks
pablosichert opened this issue May 15, 2024 · 5 comments · May be fixed by #2506
Open
1 of 3 tasks

use_memo does not properly diff inputs and drops updates #2416

pablosichert opened this issue May 15, 2024 · 5 comments · May be fixed by #2506
Assignees
Labels
bug Something isn't working hooks Changes to built-in hook package signals Related to the signals crate

Comments

@pablosichert
Copy link

Problem

Currently, when using use_memo, some updates are dropped, and some updates are identical to the previous one.

Steps To Reproduce

See #2415 for reproduction test case and expected result.

I suspect this could be related to #2415 and #2370.

Questionnaire

  • I'm interested in fixing this myself but don't know where to start
  • I would like to fix and I have a solution
  • I don't have time to fix this right now, but maybe later
@ealmloff ealmloff added bug Something isn't working hooks Changes to built-in hook package signals Related to the signals crate labels May 15, 2024
@ealmloff
Copy link
Member

ealmloff commented May 16, 2024

Here is a smaller reproduction of the issue:

#![allow(non_snake_case)]

use dioxus::prelude::*;

fn main() {
    launch(app)
}

fn app() -> Element {
    let mut count = use_signal(|| 0);

    let memorized = use_memo(move || count());

    let mut effect_run_count = use_hook(|| CopyValue::new(0));

    // This effect should only run once, because the memo only ever reads as 1
    use_effect(move || {
        // trigger a sync update on memo. This will mark the effect as dirty
        if *count.peek() == 0 {
            count += 1
        }

        println!("{memorized}");
        effect_run_count += 1;
        assert!(effect_run_count() <= 1, "This effect should only run once");
    });


    rsx! { "hello world" }
}

Memo<T> is recomputing the value when you read the memo inside the effect. Recomputing the value sets the signal with the memorized value which causes all reactive closures that read the memo to rerun, including the effect that it recomputed the value inside.

We can fix this issue by unsubscribing to all signals before rerunning reactive scopes (use_memo, use_effect, use_resource, components). With that fix, the effect should not be subscribed to the memo until the effect is finished running which avoids the duplicate run (#2158)

@pablosichert
Copy link
Author

Memo<T> is recomputing the value when you read the memo inside the effect.

Why is recomputing the value necessary at that point?

@ealmloff
Copy link
Member

Memo<T> is recomputing the value when you read the memo inside the effect.

Why is recomputing the value necessary at that point?

Memos use a push/pull based system to try to maintain consistent. They don't recompute until one of these two conditions is met:

  1. The value is read
  2. All other rendering is done
let mut count = use_signal(|| 0);
// memorized will run once to get it's initial value
let memorized = use_memo(move || count() * 2);
// memorized is marked as dirty, but doesn't rerun - Lazily reruning lets us skip calculating the memo value when count = 1
count += 1;
// memorized is marked as dirty, but doesn't rerun
count += 1;

// memorized is read so it is rerun - this means we can never observe an out of date value
println!("{memorized}");

// memorized is marked as dirty, but doesn't rerun
count += 1;

// Once the component (and any parent components are done rendering, memorized is recomputed to see if any reactive closures/components need to be rerun)

@pablosichert
Copy link
Author

Interesting, thank you for elaborating.

What happens if multiple observers read from the memo? I assume the value is recalculated on the first read, and the dirty flag is removed. The second read then gets the value without recalculating?

@ealmloff
Copy link
Member

Interesting, thank you for elaborating.

What happens if multiple observers read from the memo? I assume the value is recalculated on the first read, and the dirty flag is removed. The second read then gets the value without recalculating?

Yes, exactly. It will rerun at most once for every write to a signal that is subscribes to

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working hooks Changes to built-in hook package signals Related to the signals crate
Projects
None yet
2 participants