Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Listeners should take Into<Callback<Event>> instead of Callback<Event> #1657

Closed
1 of 3 tasks
ranile opened this issue Nov 29, 2020 · 1 comment · Fixed by #1989
Closed
1 of 3 tasks

Listeners should take Into<Callback<Event>> instead of Callback<Event> #1657

ranile opened this issue Nov 29, 2020 · 1 comment · Fixed by #1989
Labels
feature-request A feature request

Comments

@ranile
Copy link
Member

ranile commented Nov 29, 2020

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.

#[function_component(App)]
fn app() -> Html {
    let (value, set_value) = use_state(|| 0);
    html! { 
        <>
            { value }
            <button onclick=move |e| set_value(1) />
        </> 
    }
}

In the above snippet, the onclick listener being passed to button causes it to fail to compile. Writing something along the lines of

<button onclick=Callback::from(move |e| set_value(1)) />

every time becomes tedious so there should be an abstraction that converts it automatically.

I think it'd be safe to just replace Callback<Event> with Into<Callback<Event>> without causing type interference issues, right?

Questionnaire

  • I'm interested in implementing this myself but don't know where to start
  • I would like to add this feature
  • I don't have time to add this right now, but maybe later
@ranile ranile added the feature-request A feature request label Nov 29, 2020
@siku2
Copy link
Member

siku2 commented Dec 12, 2020

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants