Fix debouncing not working on first search character; add extra delay instead #2348
Conversation
Should partially address nextcloud#1729 and nextcloud#769. Signed-off-by: Robbie Cooper <cooperra@users.noreply.github.com>
This gives the user more time to type in their whole query before a search blocks the main thread. Searches for short strings often have many results that aren't really useful to the user. They also take much longer to process. This commit increases the debounce delay to 200ms for short strings three characters long or less. Longer strings still have the 50ms delay. Hopefully, this is a good balance between avoiding slowdowns for short strings and providing a snappy interactive experience for long strings.
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
|
@cooperra, I've just noticed that one of your commits isn't signed off properly. Please follow the instructions provided by DCO, so that we can merge this pull request. |
For some unknown reason, debouncing was specifically avoided for the first character. This is weird because it's where debouncing is needed most, especially for long files where a single-character search can hang the app for a long time.
I don't think this will fix everything about long-running searches, but debouncing all characters will at least match expectations, allowing people to attempt to type quickly to avoid them.
Since 50ms seemed very quick (a three-frame window at 60 fps), I decided to use a longer delay (200ms) for short searches three characters long or less. The original delay is retained for other lengths, where interactive incremental behavior is more useful and won't hang the app if it happens accidentally.
Should partially address #1729 and #769.