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
If it's run as it is (commit ID 5038489), the client JS+WASM will display the following warning:
At /.../leptos/reactive_graph/src/wrappers.rs:477:35, you access a reactive_graph::signal::arc_read::ArcReadSignal<core::option::Option<alloc::string::String>> (defined at /.../leptos/reactive_graph/src/signal/rw.rs:180:40) outside a reactive tracking context. This might mean your app is not responding to changes in signal values in the way you expect.
Which is of course not very useful, as none of the mentioned code pertains to the repository in question.
However, in src/app.rs, if line 25 is commented and line 24 uncommented:
#[component]
pub fn App() -> impl IntoView {
- // let (x, set_x) = signal("Test");- let (x, set_x) = use_cookie::<String, FromToStringCodec>("test");+ let (x, set_x) = signal("Test");+ // let (x, set_x) = use_cookie::<String, FromToStringCodec>("test");
view! { <button>{x.get()}</button> }
}
Then the new code will not produce any warning at all — which I believe is wrong, because the signal access in line 27 is still not tracked. In fact, the signal access is exactly the same; only the signal definition is different.
Leptos Dependencies
leptos = { version = "0.7.0", features = ["nightly"] }
leptos_meta = { version = "0.7.0" }
leptos_actix = { version = "0.7.0", optional = true }
leptos_router = { version = "0.7.0" }
Run with e.g. cargo leptos watch --hot-reload --bin-features=ssr_actix (see README)
Access the application in your browser
Open the developer tools console and see the warning
Optionally do the mentioned modifications and see the absence of any warning
Expected behavior
I expected that the warning would be shown in both cases of the example code, and that the call and definition sites presented on the warning would not point to code internal to the project.
When I was trying to understand this behavior, I noticed that, if I changed ArcRwSignal::read_only to propagate self.defined_at, instead of creating a new Location with Location::caller(), the resulting warning does include the correct signal definition, which is in leptos-use.
/// Returns a read-only handle to the signal.
#[track_caller]
pub fn read_only(&self) -> ArcReadSignal<T> {
ArcReadSignal {
#[cfg(debug_assertions)]
- defined_at: Location::caller(),+ defined_at: self.defined_at,
value: Arc::clone(&self.value),
inner: Arc::clone(&self.inner),
}
}
At /.../leptos/reactive_graph/src/wrappers.rs:477:35, you access a reactive_graph::signal::arc_read::ArcReadSignal<core::option::Option<alloc::string::String>> (defined at /.../leptos-use-0.14.0-rc5/src/use_cookie.rs:189:32) outside a reactive tracking context. This might mean your app is not responding to changes in signal values in the way you expect.
And also saw that the immediate reason why the patched example repository code does not produce a warning is because it is in the SpecialNonReactiveZone. That is all the understanding I gathered.
The text was updated successfully, but these errors were encountered:
Describe the bug
Consider this small repository: https://github.com/veigaribo/leptos-reactive-tracking-warning-issue
If it's run as it is (commit ID 5038489), the client JS+WASM will display the following warning:
Which is of course not very useful, as none of the mentioned code pertains to the repository in question.
However, in
src/app.rs
, if line 25 is commented and line 24 uncommented:Then the new code will not produce any warning at all — which I believe is wrong, because the signal access in line 27 is still not tracked. In fact, the signal access is exactly the same; only the signal definition is different.
Leptos Dependencies
Though I did some testing with
On a repository checked out on tag v0.7.0
To Reproduce
Steps to reproduce the behavior:
cargo leptos watch --hot-reload --bin-features=ssr_actix
(see README)Expected behavior
I expected that the warning would be shown in both cases of the example code, and that the call and definition sites presented on the warning would not point to code internal to the project.
Additional context
use_cookie
is defined here: https://github.com/Synphonyte/leptos-use/blob/18cdd812f292ba83443bf868957291aedf1d9585/src/use_cookie.rs#L145. I kept it from my actual application code, where I found this issue, because I don't yet know what causes it to behave differently.When I was trying to understand this behavior, I noticed that, if I changed
ArcRwSignal::read_only
to propagateself.defined_at
, instead of creating a new Location withLocation::caller()
, the resulting warning does include the correct signal definition, which is inleptos-use
.And also saw that the immediate reason why the patched example repository code does not produce a warning is because it is in the
SpecialNonReactiveZone
. That is all the understanding I gathered.The text was updated successfully, but these errors were encountered: