Non-'static signals

[Bajix]

I'm confused about why Leptos considers 'static signals an innovation; to me, it looks very inefficient and poorly thought out. Is there any work going on to explore more efficient reactivity concepts, such as by building on top of qcell::LCell and bumpalo

[gbj]

Just for the sake of context and to provide a more helpful response: How much Rust UI code have you written/using which frameworks?

[Bajix]

I've built Rust UI for Xbox, Playstation, Desktop, iOS, Android and for automotive media centers. I've used Iced, Disney's in house framework, and another proprietary framework.

[gbj]

That's helpful. I can't speak to the proprietary frameworks of course, but re: Iced see my other comment about the expense of diffing, which is my understanding of how it works. If the proprietary frameworks are immediate-mode, we're just comparing apples and oranges. If they're callback-based retained mode, I'm not sure how they could work without 'static state containers of one kind or another, but I know that a DOM-based web framework cannot.

[Bajix]

Yea reactive frameworks are definitely superior to diff based frameworks. Async only needs 'static for spawn futures but an async reactive event-loop can be non-'static.

[gbj]

The short version: non-'static signals are useless for retained-mode UI code; but 'static signals are also not an innovation (it's the Copy part that is)

The medium version: Creating something like an event listener in the DOM requires that the function you use as an event listener be 'static. Likewise, spawning a Future via wasm-bindgen-futures requires that the Future be 'static. Capturing a non-'static reference means that the event handler or Future is no longer 'static.

This should hopefully sense because of the way a Rust UI runs, especially when it is building on top of another retained-mode UI toolkit like the DOM. Running something like a start() function will:

1. run your component code, creating some signals, DOM elements, and effect to bind signals to DOM elements
2. mount those DOM elements
3. return

After 3, the only things that still exist are those things that have passed ownership into JS, in one way or another: references created anywhere in the call stack can't outlive start(). (Nor can you just block indefinitely and never return from start, because the browser environment is single-threaded, so the page will simply be frozen.)

As a result it's pretty straightforwardly true that either
a) whatever unit of state you use needs to be 'static, or
b) you need to use a bunch of unsafe code to pretend that it doesn't need to be

A) is the typical path in Rust UI frameworks.
B) Sycamore 0.8 and Dioxus pre-0.5 experimented with putting lifetimes on components and tying the lifetimes of state to those lifetimes, and have both dropped that approach for different reasons.

There is actually an approach C (see Iced, Sauron) in which things like event listeners do not have any access to state at all, but just return a message type. This is elegant, verbose, and hides a huge amount of VDOM overhead from users; it feels good to say "yes I have a fn view(&self) and a fn update(&mut self, msg: ...), that looks like clean Rust code — it just involves doing a huge amount of inefficient VDOM diffing work after you run the update.

The long version: So, pretty much all Rust UI frameworks use 'static state and I'm not sure why this would be surprising, but it's also not particularly innovative. Most of them are just backed by an Rc<_>. What's innovative (and what makes the framework much more usable for working with UI in Rust) is that the signals are Copy, in the same way that a reference would be, but do not have lifetimes.

To compare the same simple example in Yew and Leptos.

Yew:

    let state = use_state(|| 0);

    let incr_counter = {
        let state = state.clone();
        Callback::from(move |_| state.set(*state + 1))
    };

    html! {
        <button onclick={incr_counter}> {*state} </button>
    }

Leptos:

   let state = RwSignal::new(0);

   let incr_counter = move |_| state.update(|n| *n += 1);

   view! {
       <button on:click={incr_counter}> {*state} </button>
   }

The difference here is simply a matter of whether you need to clone into the closure or not. This is not a big deal for a one-line example but is genuinely painful in the case of larger applications, nested components, etc. (For more on the clone into closure pattern, see here.)

What Leptos does is simply to use an arena to allocate signals per reactive owner, and give you a Copy handle in exchange. This makes it extremely convenient to move signal handles into as many closures, event listeners, etc. as necessary. They are then deallocated when their reactive owner drops them, in predictable ways. If you want to read more about that process you can find a long discussion in the book.

It's not clear to me whether you say it's "inefficient" because of a misunderstanding of how/when signals are disposed, or whether you're just being hardcore and the overhead of the arena seems bad to you.

[Bajix]

...or whether you're just being hardcore

To me, there seems like a lot of implementation overhead and that there are many ways to improve upon this to create signal types that compile-time optimize better.

references created anywhere in the call stack can't outlive start().

If &bumpalo::Bump is passed into start then references created inside of start could be held for the entire lifetime

Likewise, spawning a Future via wasm-bindgen-futures requires that the Future be 'static

It's also an option to extend the lifetimes of thread locals. Take a look at my project async-local

you need to use a bunch of unsafe code to pretend that it doesn't need to be

It's a very Rust thing to safely encapsulate unsafe code. I only use unsafe 100 times in my project stack-queue 😂

[gbj]

I will look forwarding to learning from your implementation of a more efficient approach!

[gbj]

(I'm not trying to be dismissive, by the way—I just think without comparing two existing things it's really hard to judge the trade-offs. I do not pretend that this is the most efficient possible implementation of a reactive system in Rust. It absolutely is not. But to the best of my knowledge it is the most ergonomic way to introduce fine-grained reactivity into wide use in Rust web UI, and that's what I am mostly interested in.)

[tqwewe]

@Bajix sounds like you might be able to create a great Rust UI library outperforming Leptos in efficiency, developer experience, and more thought out. Please tag me here if you do that would love to switch over if that's the case.

[Bajix]

This example from my project async_local demonstrates how the lifetime can be constrained using Higher-Rank Trait Bounds while still being used in a place requiring 'static:

  pub fn with_blocking<F, R>(self, f: F) -> JoinHandle<R>
  where
    F: for<'a> FnOnce(LocalRef<'a, T>) -> R + Send + 'static,
    R: Send + 'static,
  {
    let local_ref = unsafe { std::mem::transmute(self) };

    spawn_blocking(move || f(local_ref))
  }
}

In the above example, this is sound because the runtime shutdown barrier prevents any task from outliving any worker thread, therefor making every invariant lifetime sound - even though the closure passed into spawn_blocking is 'static, the lifetime of LocalRef<'a, T> can never be extended to be 'static, and so it cannot be moved into a non-scoped thread or otherwise escape the closure.

What needs to happen to guarantee the safety of non-'static signals within event listeners is to make it so that the wasm_bindgen::closure::Closure is constructed so that it calls a Fn using a lifetime constrained by HRTB and then additionally it must be guaranteed that neither the event listener nor the element itself can outlive the signal. Perhaps this can be via a reactive context that uses a bump allocator.

For futures spawned with wasm-bindgen-futures that load resources, generational-arena can be used to establish where the bytes will be eventually written to so that the load state can be observed by passing around the index and can be updated from a stream of responses combined with the index previously assigned. The future itself never needs a reference to the generational-arena and can be 'static as a consequence

[Bajix]

The medium version: Creating something like an event listener in the DOM requires that the function you use as an event listener be 'static. Likewise, spawning a Future via wasm-bindgen-futures requires that the Future be 'static. Capturing a non-'static reference means that the event handler or Future is no longer 'static.

This should hopefully sense because of the way a Rust UI runs, especially when it is building on top of another retained-mode UI toolkit like the DOM. Running something like a start() function will:

1. run your component code, creating some signals, DOM elements, and effect to bind signals to DOM elements
2. mount those DOM elements
3. return

Another option is to spawn a future with wasm-bindgen-futures that encapsulates the entire lifecycle of the app, and within this interior futures can be non-'static and borrow from an outer context without needing to block start