how to stop the reactive system on v0.5?

[flisky]

Like your answer in #1306 (reply in thread), but I'm prototyping with leptos_reactive with a mpsc "result channel" on the v0.5 edge branch. There are neither view nor cx. How could I dispose the create_effect? It seems create_effect is also a ReactiveNode, which could be disposed? Thanks in advanced!

[gbj]

An example of what you're doing would be helpful here. All reactive nodes are now owned by the reactive node (effect or memo) that they're created inside, and will be disposed when it re-runs.

[flisky]

I write a test case, and hope it clarify the use case.

#[cfg(test)]
mod tests {
    use std::collections::HashMap;

    use leptos::{
        create_isomorphic_effect, create_rw_signal, on_cleanup, store_value, RwSignal, SignalGet,
        SignalSet, StoredValue,
    };

    #[tokio::test]
    async fn test() {
        let runtime = leptos::create_runtime();
        let stocks = store_value(HashMap::<String, RwSignal<usize>>::new());

        fn component(stocks: StoredValue<HashMap<String, RwSignal<usize>>>) {
            let res = leptos::create_resource(
                || (),
                |_| async move {
                    tokio::time::sleep(std::time::Duration::from_secs(1)).await;
                    vec!["A".to_string()]
                },
            );
            let counters = move || {
                if let Some(counters) = res.get() {
                    for counter in counters {
                        stocks
                            .get_value()
                            .entry(counter)
                            .or_insert_with(|| {
                                let v = create_rw_signal(1);
                                v
                            })
                            .get();
                    }
                }
            };
            create_isomorphic_effect({
                move |_| {
                    on_cleanup(|| {
                        println!("cleanup");
                    });
                    counters();
                    println!("rendering ...");
                }
            });
        }

        let local = tokio::task::LocalSet::new();
        local
            .run_until(async move {
                // multi instance for same component
                let _component1 = component(stocks);
                let _component2 = component(stocks);

                // background to trigger stock changes
                let handle = tokio::spawn(async move {
                    tokio::time::sleep(std::time::Duration::from_secs(1)).await;
                    if let Some(signal) = stocks.get_value().get("A") {
                        signal.set(3);
                    }
                });

                // how to abort the effect of _component1 because it doesn't need any more ???

                handle.await.unwrap();
            })
            .await;
        runtime.dispose();
    }
}

[gbj]

So in this particular example it's disposed when you call runtime.dispose()

                // how to abort the effect of _component1 because it doesn't need any more ???
                handle.await.unwrap();
            })
            .await;
        // it's disposed here
        runtime.dispose();

If you need to stop an effect early, you should probably use watch instead.

Outside a test case like this, of course, you don't want to dispose of the effects early — they should remain running so they continue listening to changes in the stock values.

So if the intention is just to make sure it doesn't leak while running the test, then the runtime.dispose() is sufficient to do that. If not, then could you clarify for me what you're trying to achieve?

[flisky]

Yes, I don't want to call runtime.dispose(). In my usecase, I really want to dispose one particular component instance. Say something like a portfolio component for different users, I would like to mount & unmount it. Without early dispose, it will waste cpu, leak memory, and/or mental burden with signal lifetime, I think?

[gbj]

Conceptually, when you're using a reactive system like this one your whole application should be a set of nested effects, so mounting or unmounting a component should be managed by some kind of effect. Here's an example using some GUI pseudo-code:

let (show_component, set_show_component) = create_signal(false);

let container = Container::new();

create_effect(move |_| {
  if show_component() {
    container.append_child(some_component());
  } else {
    container.clear();
  }
});

fn some_component() -> Widget {
  let (data, set_data) = create_signal();
  create_effect(move |_| {
    println!("{}", data());
  });
  // return the widget
  todo!()
}

In this case, what owns the signal and the effect created in some_component() is the effect that creates them. When that effect re-runs, it disposes of its children. Nothing additional needs to be done to dispose of some_component or the effect created inside it.

The whole leptos_dom renderer ends up creating a series of nested effects like this. This is how any renderer built using this kind of reactive system should ultimately work. Mounting or unmounting a component just means creating some widget and setting up a reactive system by calling a component function, inside some effect that reacts to changes. If it's inside an effect, it will be automatically disposed when the effect runs. If it's outside an effect, there's no way to reactively unmount it anyway.

[flisky]

Thank you for the anwser. I was wondering we could dispose the ReactiveNodeType::Effect node, and it turns out not. I'll try to use a signal with a top level create_effect instead of multi top level ones.

[gbj]

If it's something that's really necessary for your use case, and you want to create a version of create_effect that actually returns something you can call .dispose() on—a PR would be totally fine. At the moment creating an effect doesn't return anything, so it's not possible to dispose of it, because it's all managed automatically. There's no technical reason that a ReactiveNodeType::Effect can't be disposed (and in fact they are disposed!), this type just isn't exposed as part of the public API because exposing it has never been necessary to Leptos itself.