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
Describe the feature you'd like
Currently, listeners take value of type Callback<Event>. They should take Into<Callback<Event>> instead.
Is your feature request related to a problem? Please describe.(Optional)
There is no self.link.callback(...) abstraction in function components so it becomes to do Callback::from(|e| ...) every time there is a need to pass a callback.
Sadly, without specialization this is gonna be somewhat hard to implement with #1637 in mind...
I have thought about this and I like the idea of not having to write Callback::from but there are a few things to keep in mind:
we want to unify element props with component props so this needs to work for any prop with type Callback
thanks to the decision to go with implicit optional attribute we have to make sure that this also works for Option<Callback> (which is a mess to implement currently)
we don't want to generalize this to any Into<T> either because that causes all kinds of issues down the line
Rust really doesn't encourage this sort of design so every step of indirection results in worse error messages and longer compile times.
So honestly I'm not sure how to go about this in a way that doesn't have a ton of downsides...
Describe the feature you'd like
Currently, listeners take value of type
Callback<Event>
. They should takeInto<Callback<Event>>
instead.Is your feature request related to a problem? Please describe. (Optional)
There is no
self.link.callback(...)
abstraction in function components so it becomes to doCallback::from(|e| ...)
every time there is a need to pass a callback.In the above snippet, the
onclick
listener being passed to button causes it to fail to compile. Writing something along the lines ofevery time becomes tedious so there should be an abstraction that converts it automatically.
I think it'd be safe to just replace
Callback<Event>
withInto<Callback<Event>>
without causing type interference issues, right?Questionnaire
The text was updated successfully, but these errors were encountered: