Open ralfr opened 1 year ago
At least on iOS, there’s currently throttling to once every 500ms. That said, it might make sense to increase it?
I think that if we are introducing adjustments to the debounce, we should consider also adding some responsive feature like an ActivityIndicator
or showing the RefreshControl
on the Tableview. It would reinforce the idea behind #655
Is there an existing issue for this?
Current Behavior
When users type into the search field, every keystroke is send to the backend. Likely this is meant to enhance the user experience and provide a classical type-ahed search experience.
However, given the complexity of the database queries executed on the backed, this causes a ton of load on the backend side PostgreSQL database, which is essential for the entire performance of any instance.
We've seen the iOS app causing literally thousands of complex queries looking for "R", then for "RA" then for "RAL" then for "RALF" and so on.
Expected Behavior
Type-ahead should be implemented in a way where, e.g.: The client waits until the user has at least provided three characters AND there was a typing pause of 800 ms or higher.
Steps To Reproduce
n/a
Environment
Anything else?
No response