You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I unfortunately ran into the need to call an async fn(&mut self) function on a type that exists inside a Signal.
Code looked something like:
let sig = use_signal(||MyAsyncType::new())rsx!{Button{
onclick: move |_| async move {//Problem is here, we are holding a lock across an await point without realizing
sig.write().increment(5).await;},"+5"}}
Due to me not doing a good enough job of reading the docs, I quickly started having panics all over the app.
I did eventually figure out that this was the issue, and found docs explaining that the dioxus idiomatic way around this was to do something like:
This ends up very cluttered and error prone if I forget to set the signal back to the temporary value, I ended up playing around with the idea of a write_on_drop() method to accomplish the same thing, and wondered if there was anything I'm missing on why this is a bad idea as it seems to work well.
With my write_on_drop() method the code ends up looking like:
rsx!{Button{
onclick: move |_| async move {//example 1{//with write_on_drop, value is cloned, and then set back after the await point
sig.write_on_drop().value().increment(5).await;}//example 2{//alternatively if you need to do many operations you would do something like letmut temp = sig.write_on_drop();
temp.value().increment(5).await;
temp.value().set(0).await;
info!("The current state of the temp cloned value before actually updating the signal: {:?}",&*temp.value());//Does not compile, as we are holding &mut sig inside temp, so you don't read "stale" value by accident//sig.read()//Only here does temp get dropped and actually update the value//alternatively you can call drop(temp) yourself}},"+5"}}
From my very limited testing this does seem to work as expected. It could also be named something like async_safe_write() to help guide users to the happy path.
The actual code for this is under "WriteOnDrop impl code" below, I wrote this with very little thought, so this specific impl may have issues but is just to get the general idea across, and put it here incase anyone wants to try it out.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I unfortunately ran into the need to call an
async fn(&mut self)function on a type that exists inside a Signal.Code looked something like:
Due to me not doing a good enough job of reading the docs, I quickly started having panics all over the app.
I did eventually figure out that this was the issue, and found docs explaining that the dioxus idiomatic way around this was to do something like:
This ends up very cluttered and error prone if I forget to set the signal back to the temporary value, I ended up playing around with the idea of a
write_on_drop()method to accomplish the same thing, and wondered if there was anything I'm missing on why this is a bad idea as it seems to work well.With my
write_on_drop()method the code ends up looking like:From my very limited testing this does seem to work as expected. It could also be named something like
async_safe_write()to help guide users to the happy path.The actual code for this is under "WriteOnDrop impl code" below, I wrote this with very little thought, so this specific impl may have issues but is just to get the general idea across, and put it here incase anyone wants to try it out.
WriteOnDrop impl code
I'm currently using this across my app with seemingly no issues, so just thought it could be a good idea to share.
All reactions