-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Refactor and simplify Callback
#2269
Comments
If there's no objections, I will PR this change (hopefully) soon. |
A callback that can only be executed once might be useful for situations where you'd like to limit the user from repeating an action (i.e. payment submission). Though panicking is not terribly helpful here. That being said I don't see a use case where it is the only solution. |
Right. Any such situation can be dealt by the user on a per-case bases. In current implementation, I feel like it also adds too much of a runtime to justify using |
Making Callback non-Clone would remove the ability to pass a callback that a component is given in its props directly down into a sub-component without creating an intermediate callback. This is a pattern that occurs reasonably frequently in my codebase. I could work around it, but it'd be a little annoying. |
@rjmac, you're right. That would be incontinence and could read to |
Don't even need the The workaround I was thinking of is a bit ugly, instead of passing down the callback you got in your props you pass down a fresh callback that sends you a message to emit the callback from your props. |
@intendednull This is usually called debouncing. And using FnOnce is not the way to implement it as FnOnce panics if you call it a second time. |
@hamza1311 I think Callback could also return values Main case is when im passing half-filled route enums inside a callback so that when on event i have the missing data i just call the callback. |
yew::Callback
should be refactored to make the following changes:Remove
CallbackOnce
:is a pretty complex type with a many indirections. We should remove it altogether
Move the
passive
option somewhere elsepassive
is event listener specific, notCallback
specific. It should be a set as part of listener API, not theCallback
one.passive
inCallback
increases it's complexityReplaceRc<_>
withBox<_>
/RemoveClone
implementationRc<dyn Fn(IN)>
will becomeBox<dyn Fn(IN)>
. With #1961, there is no need for props to beClone
so callback doesn't need to beClone
either. We could save the overhead of reference counting by usingBox
here instead.Update: it seems this is a bad idea
Get rid of reform
It's a helper which isn't used much (4 usages in the entire yew repo). #2196 has discussion about it that ended with it's existence not really mattering
Callbacks should also return values
By default, the return value can just be
()
but there should be a way to specify it.Potential future changes
Use static dispatch instead of dynamic dispatch for
Fn
:type_alias_impl_trait
feature (rust-lang/rust#63063) would allow it.The text was updated successfully, but these errors were encountered: