How to use the Debouncer with HxMultiSelect filtering?

[bholbrook]

I've been having performance issues with the HxMultiSelect filtering for a while now on slower connections as (especially with larger lists), as when the user types in the filter box the items are filtered upon every key input.
I'd love to be able to change this so that debouncing is used to prevent filtering until the user stops typing for some time.

The example outlined here https://havit.blazor.eu/concepts/Debouncer showcases how to use the Debouncer for a very simple text-based input control but as the HxMultiSelect filter text property isn't exposed, and as it doesn't seem to allow BindEvent and probably other things I'm missing, I don't see a way to implement this.

Might this be possible? Or is debouncing something that would need to be implement specifically for this component?

[hakenr]

Hello,
HxMultiSelect does not support partial loading of the data. The Data parameter should be assigned a full list of items, where the FilterPredicate allows you to customize the filtering condition (executed over all the Data). In such a setup, it does not make sense to debounce the filtering, as the FilterPredicate is not expected to communicate with the API or be otherwise expensive.

The intended usage scenario is to download the data once from the API, save it in a local field, and use it for the Data parameter of the HxMultiSelect for the entire time it is displayed. For repeated usage of the same data, client-side caching using DictionaryDataStore might be helpful.

[bholbrook]

What you're saying definitely makes sense and in my use case I am loading the data once. I think it's partially as my list is quite lengthy (currently ~300 entries with a very real possibility of it growing into the thousands) and because of the slower connection.
I'm not completely sure if it's the UI re-rendering that's slowing things down or the data itself.

I was hoping a Debouncer might be useful generally for the HxMultiSelect for all users as even if the data was smaller or on a faster connection it would mean that the component doesn't have to re-render every single time a user enters a new character, instead opting to wait until a full string has been entered before performing any rendering.

If that's not an option then I understand and will see if I can redesign my application to utilise different components in different ways, but if it is an option I think it could be beneficial.

As always, very open to discussion. Thank you again.

[hakenr]

Debouncing the filtering could make sense, especially for interactive server-side rendering, where delaying the keystrokes before applying the new filter could make the UX smoother. You would need to remember the previous filter query and use it in FilterPredicate for responses before the new query takes effect. Since the results of such queries will be the same, the Blazor diffing algorithm will result in no "expensive" DOM changes.

Our Debouncer is probably not the best fit to implement such logic, as it is intended for other usage scenarios where the debounced logic is asynchronous.

(Debouncing the keystrokes in JavaScript before raising the Blazor event, i.e., before any communication with the server for interactive server-side rendering, could make the UX even smoother. However, to be honest, we don't do this even for much more exposed components such as HxAutosuggest or HxSearchBox, where we still listen to all the keystrokes in Blazor and do the debouncing there.)