add override option for `debounce` and `throttle`

[the example references debounce - but everything is true for throttle as well]

consider the following scenario:

a search input, that is bounded to some property in the VM.

typing into the input need to initiate some kind of search from the backend in “real time”. hitting “Enter” in this same input initiate another method that also need the value of the input.

we typically don’t want to initiate the search immediately after each keystroke, so we actually use the debounce binding behavior (bb from now on). this will cause the binding to refresh the VM only after some amount of time has passed without the user typing anything new. barely visible to the human eye - but helps a lot with performance.

but now we have a problem: if a user types really fast and hits “Enter” - before the binding had a chance to update the value. the value of the input in the VM is still undefined (or whatever the last old value was) instead of the “real” text the user typed.

we need to allow some kind of override for the debounce bb, that will flush the value immediately. for AU1, I’ve created a copy of the debounce bb, that “flushes” the value whenever “Enter” was pressed. and I was thinking of making the same fix for AU2.

but this time, I think this should be baked in original bb itself (and controlled via some kind of smart option), instead of being another copy and almost similar bb.

🙋 Feature Request

enable some sort of override for debounce and throttle binding behaviors - that will flush the value immidiattly.

🤔 Expected Behavior

• default: default timeout. no overrides. <input value.bind="myValue & debounce" >

• provided timeout. no overrides. <input value.bind="myValue & debounce:200" >

• provided timeout. with one override. <input value.bind="myValue & debounce:200:'Enter'" >

• provided timeout. with more overrides. <input value.bind="myValue & debounce:200:'Enter':'Space'" >

this is not a good syntax. I would love to hear other thoughts and ideas regarding this.

EDIT: new syntax based on @zewa666 comments.

• default: default delay. no flush overrides. <input value.bind="myValue & debounce" >

• provided delay. no fulsh overrides. <input value.bind="myValue & debounce:200" >

• default delay. with a single flush override. <input value.bind="myValue & debounce:'Enter'" >

• default delay. with an array of flush overrides. <input value.bind="myValue & debounce:['Enter', 'Space']" >

• complex option. (where you can specify delay, overrides (single or array), and more if needed…) <input value.bind="myValue & debounce:{delay: 200, flushOn: 'Enter'}" > <input value.bind="myValue & debounce:{delay: 200, flushOn: ['Enter', 'Space']}" > <input value.bind="myValue & debounce:{flushOn: ['Enter', 'Space']}" > <input value.bind="myValue & debounce:{delay: 200}" > etc…

😯 Current Behavior

there is no way to express this kind of behavior.

💁 Possible Solution

1. reading the value from the DOM instead of the binding if we want to be sure to have the “latest” value.
2. waiting the amount of time specified by the debounce before each operation regarding the value. (not really a solution: because the user might keep on typing - further delaying the binding flush)

[zewa666]

I like this idea. How about though accepting still one param. If number, treat it like delay timeout. If object then it could have a delay and e.g flushOn: ("space" | "enter")[]? That way we’d stay flexible for potential future options

[nenadvicentic]

My feeling is that this is overcomplication of debounce and would probably overcomplicated implementation as well.

What if I also need to flush debounce on a button click? Or, I’m expecting Enter to triggers button click on the form with multiple input fields, all flushed? Should propertyChanged method be able to detect if it was called after normal debounce or after flush? What if my debounce time is much longer and I end up needing to flush 2 input field values?

To me something about this proposed feature smells pretty bad.