Why does this only crash when I've navigated to a different page before?

[nnmm]

In this demo, deleting an item from a list on page A works if I visit page A directly, but if I navigate to page B and then back to page A, it crashes. The crash is caused by leptos unexpectedly running a closure that belongs to the deleted item (check the console to convince yourself) and thereby accessing a disposed signal.

Am I correct in imagining the reactive graph to look like this?

               —>  memo —> closure —> update DOM (of the deleted element)
            /
ingredients 
            \
              —> <For> action (removes list element)

If yes, what determines the order of the actions running (which seems to be affected by which page I've navigated to) and how can I ensure the right one runs first?

use leptos::prelude::*;
use leptos_router::components::{Outlet, ParentRoute, Redirect, Route, Router, Routes, A};
use leptos_router::path;
use reactive_stores::*;
use std::collections::HashMap;

#[derive(Clone, PartialEq, Eq, Store)]
pub struct Ingredient {
    pub key: usize,
    pub name: String,
}

#[derive(Clone, Store)]
pub struct AppData {
    #[store(key: usize = |keyed| keyed.key)]
    pub ingredients: Vec<Ingredient>,
}

#[component]
pub fn App() -> impl IntoView {
    view! {
        <Router>
            <Routes fallback=|| "Not found">
                <ParentRoute path=path!("") view=Frame>
                    <Route path=path!("") view=|| view! { <Redirect path="a" /> } />
                    <Route path=path!("a") view=PageA />
                    <Route path=path!("b") view=PageB />
                </ParentRoute>
            </Routes>
        </Router>
    }
}

#[component]
fn Frame() -> impl IntoView {
    let plan: Store<AppData> = Store::new(AppData {
        ingredients: vec![
            Ingredient {
                key: 1,
                name: "Flour".to_string(),
            },
            Ingredient {
                key: 2,
                name: "Eggs".to_string(),
            },
        ],
    });
    provide_context(plan);

    // Mock data, in reality this would be derived from a list of recipes that reference ingredients.
    // What is important is that it depends on the ingredients list.
    let memo: Memo<HashMap<String, usize>> = Memo::new(move |_| {
        plan.ingredients().read();
        HashMap::from_iter([("Flour".to_string(), 3), ("Eggs".to_string(), 5)])
    });
    provide_context(memo);

    view! {
        <nav class="w-full flex text-lg text-color-neutral-700 shadow-md">
            <A href="a" attr:class="nav-element flex-1 bg-a hover:bg-a-hover">"Page A"</A>
            <A href="b" attr:class="nav-element flex-1 bg-b hover:bg-b-hover">"Page B (click me!)"</A>
        </nav>

        <main class="p-8">
            <Outlet />
        </main>
    }
}

#[component]
pub fn PageB() -> impl IntoView {
    view! {
        <p>"Now go back to page A and click the trash icon with the console open"</p>
    }
}

#[component]
pub fn PageA() -> impl IntoView {
    let appdata = use_context::<Store<AppData>>().expect("AppData store was provided");
    let ingredient_stats =
        use_context::<Memo<HashMap<String, usize>>>().expect("Memo was provided");
    view! {
        <p class="mb-4">"If you delete an ingredient here, it works. However, if you first navigate to page B and back, it will not work."</p>
        <div class="ingredients-grid sticky bg items-end top-0 z-10 text-gray-700 border-b">
            <div class="px-2 py-1">"Ingredient"</div>
            <div class="px-2 py-1">""</div>
            <div class="px-2 py-1">"Used in this many recipes (signal)"</div>
        </div>

        <ul>
            <For
                each={move || appdata.ingredients()}
                key={move |wrapper| wrapper.key().get()}
                let(wrapper)
            >
                <li>
                    <Ingredient
                        ingredients_list=appdata.ingredients()
                        key=wrapper.key()
                        ingredient=wrapper.name()
                        used_in_recipes= move || {
                            tracing::info!("Closure running for {:p}!", &wrapper);
                            let ingredient_name = wrapper.name().read();
                            ingredient_stats.get()[ingredient_name.as_str()]
                        }
                    />
                </li>
            </For>
        </ul>
    }
}

#[component]
pub fn Ingredient(
    ingredients_list: KeyedSubfield<Store<AppData>, AppData, usize, Vec<Ingredient>>,
    #[prop(into)] key: Field<usize>,
    #[prop(into)] ingredient: Field<String>,
    used_in_recipes: impl Fn() -> usize + Send + Sync + 'static,
) -> impl IntoView {
    view! {
      <div class="ingredients-grid">
        <p>{ingredient}</p>
        <button class="px-2 py-2 rounded-xl border bg-blue-100 border-blue-200"
          on:click={move |_ev| {
              let key = key.get();
              ingredients_list.write().retain(|ingredient| ingredient.key != key);
            }}
        >
          "🗑️"
        </button>
        <p class="px-2 py-1">{move || format!("{}", used_in_recipes())}</p>
      </div>
    }
}

`main.rs` and `Cargo.toml`

use leckerschmecker_web::App;

fn init_tracing() {
    use tracing_subscriber::fmt;
    use tracing_subscriber_wasm::MakeConsoleWriter;

    fmt()
        .with_writer(
            // To avoide trace events in the browser from showing their
            // JS backtrace, which is very annoying, in my opinion
            MakeConsoleWriter::default().map_trace_level_to(tracing::Level::DEBUG),
        )
        // For some reason, if we don't do this in the browser, we get
        // a runtime error.
        .without_time()
        .with_ansi(false)
        .init();
}

fn main() {
    init_tracing();
    console_error_panic_hook::set_once();
    leptos::mount::mount_to_body(App);
}

[package]
name = "leckerschmecker-web"
version = "0.1.0"
edition = "2021"

[dependencies]
console_error_panic_hook = "0.1.7"
leptos = { version = "0.8.14", features = ["csr"] }
leptos_router = "0.8"
reactive_stores = "0.3"
tracing = "0.1.41"
tracing-subscriber = "0.3.19"
tracing-subscriber-wasm = "0.1.0"

[gbj]

In this particular case the issue appears to be solved by using a derived signal (Signal::derive()) rather than a Memo. That suggests that the issue has to do with the laziness of memos: i.e., that their value is calculated once, and then cached, whereas a derived signal is calculated each time it's requested.

[nnmm]

Thanks, that is good to know. Unfortunately the real app slows to a crawl with Signal instead of Memo.

According to what order are the effects in the reactive graph run? According to the order in which they were created?

[gbj]

slows to a crawl

In debug mode or release mode?

According to what order are the effects in the reactive graph run? According to the order in which they were created?

Correct, effects run in the order in which they're created.

[nnmm]

Debug mode, but in release mode a single interaction/page load still takes more than 20s.

[gbj]

Ok, having spent a little more time playing around this, I think the issue is something like this:

The Memo and the For component both depend on the ingredients() field. This means that they will be notified in the order in which they subscribe to the field.

A Memo is lazy, so its body calculation won't be run until it is read for the first time.

In your case, this means on first loading /a, the order goes:

(Memo is created but not yet run)
running For each
running Ingredient
running used_in_recipes closure 0x145118
running Memo
running Ingredient
running used_in_recipes closure 0x146360
(Memo does not run again, value is just returned from it)

You navigate to /b and then back to /a, and the view is rendered again:

running For each
running Ingredient
running used_in_recipes closure 0x145ad0
unning Ingredient
running used_in_recipes closure 0x1478a8

The Memo does not run at all during this render; ingredients() has not been triggered at all, so it still has the same value and isn't re-calculated.

This means that the order in which the Memo runs relative to the effects changes depending on whether you've previously navigating.

There are a couple options that I found that worked without panicking:

1. Create the Memo on PageA, rather than in Frame. This may not be ideal depending on what other pages it's used on in reality.
2. Ensure that the Memo is tracked in the For component. I found that just doing this resolves the issue:

            <For
                each={move || {
                    ingredient_stats.track();
                    appdata.ingredients()
                }}

Note that 2 causes the For loop to run twice when you load /a for the first time, because the Memo being calculated lazily for the first time causes it to run again! However, adding a single memo.read_untracked() after you create the memo (to evaluate it eagerly) fixes this.

(Evaluating the Memo once eagerly without tracking in the For does not fix the issue.)

[nnmm]

That sorta makes sense to me, though I'm not sure I can follow the thinking exactly.

running Ingredient

By that, do you mean the component or some signal created by the #[derive(Store)] for the Ingredient struct?

This means that the order in which the Memo runs relative to the effects changes depending on whether you've previously navigating.

That's because when I'm on page B, the memo and the store still exist and the memo is still subscribed to the store's ingredients() signal, right? So when I navigate back, this time the effects that make up page A are subscribed to ingredients() after the memo?

I expect the workaround you proposed (no. 2 – I don't think no. 1 can be done in my app) to be really helpful, so thanks a lot, I'll try that out. It will be a bit more complicated because the real app has more memos than one.

[gbj]

I'm not sure I can follow the thinking exactly.

Oh, I definitely can't follow the thinking; I can explain the process of what runs when but am not totally clear on why it leads to the "stale closure" kind of issue.

By that, do you mean the component

Correct, I mean the Ingredient component. (There are two ingredients in the list so it runs twice on list creation)