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
Currently, to retrieve the contents of a Signal, you need to call the Signal struct. For example:
let signal: Signal<Option<String>> = use_signal(|| None);
if let Some(s) = signal() {
rsx!(
p {
s
}
)
}
This seems impossible at first since Signal has kind *, but calling something requires kind * -> * in order to typecheck. If I understand correctly, this is possible by abusing the auto dereferencing rules of Rust and implementing Deref with type Target = dyn Fn() -> T. I believe this is an anti-pattern that should not be used by a popular library. I found this extremely confusing and spent significant time 1) figuring out how to retrieve a T (the only mention in Signal's documentation is hidden in the Deref impl) and 2) understanding how this works.
Implement Suggestion
Remove the Deref implementation and implement a separate method (maybe get?) that retrieves the content of a Signal.
The text was updated successfully, but these errors were encountered:
The majority of methods for Signal are implemented on the Readable and Writable trait. One of the methods on the Readable trait is cloned which clones the value out of the signal.
This seems more like a docs/discoverability issue than anything else. I agree looking at the docs of Signal, it isn't clear that you can call the struct or use methods from readable and writable. It would be more clear if we included more examples in the signal docs (including calling the signal like a function) and links to the relevant traits (Readable and Writable)
Implementing the Fn trait itself would also be much more clear than Deref, but unfortunately fn_traits has not landed in stable yet.
Feature Request
Currently, to retrieve the contents of a
Signal
, you need to call theSignal
struct. For example:This seems impossible at first since
Signal
has kind*
, but calling something requires kind* -> *
in order to typecheck. If I understand correctly, this is possible by abusing the auto dereferencing rules of Rust and implementingDeref
withtype Target = dyn Fn() -> T
. I believe this is an anti-pattern that should not be used by a popular library. I found this extremely confusing and spent significant time 1) figuring out how to retrieve aT
(the only mention inSignal
's documentation is hidden in theDeref
impl) and 2) understanding how this works.Implement Suggestion
Remove the
Deref
implementation and implement a separate method (maybeget
?) that retrieves the content of aSignal
.The text was updated successfully, but these errors were encountered: