Delayed Binding

[furesoft]

Is your feature request related to a problem? Please describe. If wanting IO stuff on property change it would be better to trigger the propertychanged event after a delay

Describe the solution you'd like A Delay Property on Binding MarkupExtension

[maxkatz6]

I understand this issue is more about feature parity with WPF, but that kind of delaying is easier to control in view model layer. Especially with flexible mvvm frameworks.

[Whiletru3]

I also need the delay, especially in the slider

[RossenHristovEnscape]

We also need Binding.Delay a lot.

[timunie]

We also need Binding.Delay a lot.

what's the exact usecase here? Can't this be done (as a workaround for now) in the ViewModel using ReactiveUI's this.WhenAnyValue and .Throttle or using a DispatcherTimer?

[RossenHristovEnscape]

We also need Binding.Delay a lot.

what's the exact usecase here? Can't this be done (as a workaround for now) in the ViewModel using ReactiveUI's this.WhenAnyValue and .Throttle or using a DispatcherTimer?

Yes, this can definitely be done on the ViewModel level as I have done with a simple Debouncer using a Timer. But for every property that I need to be be debounced (i.e. delayed) I have to plague my view models with this same code. Having this functionality on the Binding level and being able to specify it in AXAML would lead to much cleaner code all around and the view models will not have to deal with this logic for every single property that they need to do so.

[timunie]

@rossen-hristov for sure in the future this can be considered, but for now we only have this "workaround". However, we need to make sure this doesn't have performance issues when implemented and it must be well tested, so nothing I see in the near future.

If you need to do it often, I can only suggest to write an attached property or a behavior which does what you need to do.

[jp2masa]

@rossen-hristov Just my opinion, but the more you can implement in the VM, the better. That way, if you eventually need to port to another framework, you don't have to duplicate any logic. In this example, you would have to duplicate the delay value between views, and if you need to update one, you need to look for all other instances to update as well.

[runelkrone]

I believe the initial use case for delay was in ListViews. When the user holds the arrow down the binding delay prevents sending change notifications for every element in the list. I generally avoid using the dispatcher in the VM whenever possible as it introduces a dependency on the UI that we generally try to avoid.

[npolyak]

Actually it is much easier to use the binding's Delay property rather than adding Throttle functionality to the View Model or adding a Throttle behavior to the UI level. So I think this feature is good to have. An example where it is needed would be changing Text within the text box bound to a VM, triggering a search every time the text is changed. There should be some Throttle interval to prevent unnecessary searches.

[aaronhernan]

Maybe... It depends. If the problem is the UI which is sending a lot of unnecessary changes due to the nature of the interface, it should be in the binding. Because another framework or another UI of a different nature wouldn't have that problem. If any UI would represent a bounce problem, it should be handled in ViewModel.

[alexhelms]

Another use case I'm running into is binding the Color property of the ColorPicker. If the user is dragging the color sliders around then that binding is firing a lot. Having a delay in the binding would help with that.