Fuzzy matching?

[buckmaxwell]

Hi, thinking of switching over from Alex repo. His code does a pretty good job for me, really the only issue that I am running into is that the searching is not fuzzy.

ie, I can search for 'Field 1 Field 2' and no results will be returned even though 'Field 1 - Field 2' might work fine. Does this implementation support or plan to support fuzzy finding?

[BozoJim]

Not yet, but this is a common request that we'd like to implement. Pull requests welcome!
With that being said, we've fixed a few other issues with the original repo. Mostly around navigation and showing/hiding the typeahead at the right times. We encourage you to give this repo a test and let us know what issues you run into.
See #8 and #11 for similar requests.

[mattzollinhofer]

I like the idea of this feature, but honestly it's not super high on my list. If anyone is interested in taking a crack at implementing this, here's my thought of the approach I'd like to see.

Minimum Viable

Allow for users of the library to provide a function that would be used as the custom matching algorithm. I can imagine that there might be many different ideas of what a custom matcher might be, so let's allow people to provide there own.

I definitely expect tests for this feature (I do for all PRs, but this one definitely needs them). If you aren't comfortable with that side of it, I'd be willing to help with that.

Bonus Points

I would be interested in providing a few different options for matchers. I haven't thought much about what the possibilities are, the obvious one that's been suggested a number of times is a matcher that removes whitespace from the query and the results for comparison. If you have other ideas please share them here before spending much time developing them to make sure we're on the same page.

[theteknocat]

Custom matching and highlighting functions seem like the most pragmatic approach. That way no assumptions need to be made, default matching is provided and works as is, and anyone can implement their own customizations for that.

I, for example, want it to be able to split what you type on spaces so it can match all your words against the results and highlight them individually.

I'll submit a pull request for allowing custom matcher and/or highlighter to be provided.

[theteknocat]

This could of course be augmented with a couple of different default options too, such as the whitespace removal. So you could set some values that affect the default matching and highlighting that meet the most common needs, or just provide your own custom functions.

That said, I think that from a user perspective, if you type more than one word in the text field you would intuitively expect it to treat those as separate words. Whether the specific application makes more sense to match all or match any is another matter, though typically with a form widget like this you expect the more you type the fewer results would appear. But I could see it sometimes being useful to match any.

In any case, though, I found that by using my fork and then implementing a custom matcher and highlighter that treat the text as separate words, I get excellent results and it works great for partial word matches, which is what others have flagged as being desirable. See attached screenshot, where I've got an autocomplete field for matching URLs in a database.

I have also attached my custom matcher and highlighter functions for anyone who wants to use them in conjunction with the changes in my pull request, or if somebody thinks that should be implemented as the default behaviour - perhaps with some options to go with it for customization, such as a choice of matching all or any.
autocompleteHelpers.zip