Have signals/StoredValues update/update_value functions return the callbacks return value about leptos HOT 6 CLOSED

Note also that I've resisted this for .update() on signals, because of the fact that event handlers require a function that returns (). Returning something from .update() means that on:click=move |_| count.update(|n| *n += 1) would need to be rewritten across the board to on:click=move |_| { count.update(|n| *n += 1); }, which is worse IMO.

We previously had an .update_returning(), which was deprecated and merged into .try_update()

I would actually suggest that

// note the change to .flatten()
if let Some(v) = stored.try_update_value(|v| v.take()).flatten() {
  // do something with v
}

is the best solution here, as it won't panic.

from leptos.

Returning something from .update() means that on:click=move |_| count.update(|n| *n += 1) would need to be rewritten across the board to on:click=move |_| { count.update(|n| *n += 1); }, which is worse IMO.

I don't think this is true. In my little test:

fn my_update<O>(f: impl FnOnce(&mut i32) -> O) -> O {
    todo!()
}

let _ = view! {
        <div on:click=move |_| my_update(move |v| *v += 1) />
    };

compiled with no problems. I think fn() -> () and fn() are identical.

from leptos.

Sorry, I'm talking about the version that returns an Option. .update() currently does not panic if you update a signal that has been disposed. .update_value() does and that should probably be changed. I will not change .update() on signals to panic if disposed and return a value.

from leptos.

Since it seems the idiomatic use case would be to always use try_update in every scenario, what is the use case for update then? And why doesn't the same apply to with which does return the inner value? I think that's rather inconsistent and definitely counter intuitive.

from leptos.

And why doesn't the same apply to with which does return the inner value?

The goal of the design decisions here is minimize panicking while making the most-common case the default one. .with() must return a value, or it's meaningless, so it defaults to panicking if disposed, and you can opt into .try_with() if that might be the case. .update() does not need to return a value in the overwhelming majority of cases, so it defaults to not panicking, and you can opt into .try_update() if you want the return value.

Unless I'm mistaken you're suggesting changing the behavior of .update() so that it is essentially .try_update().unwrap(), right? This will increase the likelihood of panicking, which is bad because panics are unrecoverable in WASM.

Since it seems the idiomatic use case would be to always use try_update in every scenario, what is the use case for update then?

I don't understand what you mean here, sorry.

from leptos.

ok, I think I understand the issue with this. Somehow I was under the impression that the callback was called every time, but ofc it makes sense that it's not being called when the signal is disposed.

from leptos.