v0.5.0-beta

[gbj]

This beta release brings us closer to 0.5.0 proper.

The big changes are dropping cx/Scope entirely. I've copied and pasted the 0.5.0-alpha release notes below for reference, along with a few notes about other changes since the alpha release. A few other changes (#1480, #1485) will be incorporated once it's ready for release.

v0.5.0 in General

Reactive System Changes

This long-awaited release significantly changes how the reactive system works. This should solve several correctness issues/rough edges that related to the manual use of cx/Scope and could create memory leaks. (See #918 for details)

It also has the fairly large DX change (improvement?) of removing the need to pass cx or Scope variables around at all.

Migration is fairly easy. 95% of apps will migrate completely by making the following string replacements:

1. cx: Scope, => (empty string)
2. cx: Scope => (empty string)
3. cx, => (empty string)
4. (cx) => ()
5. |cx| => ||
6. Scope, => (empty string)
7. Scope => (empty string) as needed
8. You may have some |_, _| that become |_| or |_| that become ||, particularly for the fallback props on <Show/> and <ErrorBoundary/>

Basically, there is no longer a Scope type, and anything that used to take it can simply be deleted.

For the 5%: if you were doing tricky things like storing a Scope somewhere in a struct or variable and then reusing it, you should be able to achieve the same result by storing Owner::current() somewhere and then later using it in with_owner(owner, move || { /* ... */ }).

There are no other big conceptual or API changes in this update: essentially all the same reactive, templating, and component concepts should still apply, just without cx.

Other New Features

Now that we don't need an extra Scope argument to construct them, many of the signal types now implement Serialize/Deserialize directly, as well as From<T>. This should make it significantly easier to do things like "reactively serialize a nested data structure in a create_effect" — this removed literally dozens of lines of serialization/deserialization logic and a custom DTO from the todomvc example. Serializing a signal simply serializes its value, in a reactive way; deserializing into a signal creates a new signal containing that deserialized value.

Other Changes

use_navigate navigate function no longer returns a value

The navigate("path", options) call now uses request_animation_frame internally to delay a tick before navigating, which solves a few odd edge cases having to do with redirecting immediately and the timing of reactive system cleanups. This was a change that arose during 0.3 and 0.4 and is being made now to coincide with other breaking changes and a new version.

If you were relying on the Result<_, _> here and want access to it, let me know and we can bring back a version that has it. Otherwise, this shouldn't really require any changes to your app.

window_event_listener and friends now return a handle for removal

This one was just an API oversight originally, again taking advantage of the semver update. window_event_listener and its untyped version now return a WindowListenerHandle with a .remove() method that can be called explicitly to remove that event, for example in an on_cleanup.

Again, shouldn't require meaningful changes.

#[component]
fn TypingPage() -> impl IntoView {
    let handle = window_event_listener(ev::keypress, |ev| {
        /* do something */
    });
    on_cleanup(move || handle.remove());
}

Expected to Not Work

leptosfmt and cargo leptos --hot-reload, which assume that the view! needs a cx,, will probably not work as intended and will need to be updated.

Any other ecosystem libraries that depend on Leptos 0.4 won't work, of course.

---

This discussion was created from the release v0.5.0-beta.

[rakshith-ravi]

Let's goooooooo!!!!!!

[aschey]

Moving from #1488

I'm working on a custom framework built on top of leptos_reactive and I'm running into the following error with code that worked fine with v0.4: thread 'main' panicked at 'Attempted to get a signal after it was disposed.. I'm not at all familiar with how the reactive system is supposed to work, but the error seems to occur after this runs and removes a node that is later referenced:

leptos/leptos_reactive/src/runtime.rs

Line 157 in 8e03c00

self.cleanup_node(node_id);

If that line is commented out, the error does not occur.

The following code is a somewhat contrived but minimal reproduction.

use leptos_reactive::{create_effect, create_runtime, create_signal, prelude::*};
use std::{cell::OnceCell, error::Error};

fn main() -> Result<(), Box<dyn Error>> {
    let _rt = create_runtime();

    let (sig, set_sig) = create_signal(0);

    let counter_cache = OnceCell::new();
    let counter = move || {
        let (count, set_count) = create_signal(0);
        create_effect(move |_| {
            set_count.update(|c| *c += sig.get());
        });

        *counter_cache
            .get_or_init(|| {
                move || {
                    println!("count {0}", count.get());
                }
            })
    }();

    create_effect(move |_| {
        counter();
    });

    set_sig.update(|s| *s += 1);

    Ok(())
}

[gbj]

Signals are owned by the effect that they're created inside, and are disposed of when that effect re-runs. They should be used at the level of that effect or below.

In your example, you hoist a signal up into a different data structure, and then try to access it again after the effect re-runs and it's disposed.

Commenting out the line you noted works, because instead of disposing of signals it now just never cleans them up and leaks memory instead.

Not sure what you're trying to do but that's the explanation.

[aschey]

That makes sense, thanks for the explanation. For context, I'm experimenting with making a reactive system that works with ratatui. I was trying to use Lazy/OnceCell under the hood as a simple approach to prevent setup logic from running more than once in the component tree since ratatui uses an immediate mode paradigm and the whole thing is just a big event loop that rebuilds the UI any time a state update gets triggered. I'll re-think the approach and figure something else out.