Unresponsive search bar with long entries

[ncclementi]

Bug description

When using the search tool bar, after few sequentially entered items, the bar becomes irresponsive. In the video I'm typing at a normal speed, but once I have few entries it slows down and deleting it's also slow.

This is a xref of and issue open in the Ibis repository: https://github.com/ibis-project/ibis/issues/8087

Steps to reproduce

Steps to reproduce:

• click on the search icon on the https://ibis-project.org/ website;
• type 5+ search terms;
• observe that editing becomes quickly unresponsive.
• try to delete the last word with backspace;
• observe that editing becomes quickly unresponsive.

Expected behavior

Responsive search bar.

Actual behavior

After few search terms the search bar becomes irresponsive/slow

Your environment

Tried on Firefox and Chrome.

Quarto check output

No response

[dragonstyle]

Thanks for reporting this! I think the issue is going to come down to our underlying use of Fuse.js for basic search. Fuzzy searching in Fuse.js uses Bitap algorithm which degrades based upon the length of the search contents and the pattern length. I'm not sure there is much that we can do to improve this underlying thing, but we could do a couple of things to make the experience better:

1) We could support an option that doesn't do typeahead searching and instead switches to 'press enter to search' style searching. This wouldn't specifically improve the performance, but would at least align the user experience with the slower search style.

2) We could create an optional cap on the length of terms that will be used to search and either ignore things past that point or simply prevent user input past that point.

3) I wonder if we could create a nested index in some cases and actually create a subindex to search once the input reached a certain length (to reduce the size of the contents being searched). If this actually worked, it could make things transparent to the user and acceptable - I'll tinker with that.

On the Quarto website, we use Algolia search (with a free open source license) which is more performant (and has some other benefits like search analysis to help you see what content users search for and how often they find what they're looking for). That would be one other workaround.

[dragonstyle]

Update: I just did some testing with creating a nested subindex and using that, which seems to work well. I'll try to get that into the product ASAP!