Skip to content

Fuzzy match, (potentially) expose matching algorithm, perf, styling, async API, etc. #114

Description

@chenglou

(I understand if this isn't a big concern right now)

sou should probably match South Australia. Basically, fuzzy search that matches substrings (I keep forgetting the actual name of this), or conceptually adding .* after each letter in the search query regex.

API concerns

You can probably just expose a prop filterFunc f(query, potentialMatch): bool, with a sane default being the current internal filterOptions (maybe exported as ReactSelect.defaultFilter or simply used as the default value of filterFunc). Fuzzy match libraries are available everywhere, but you can also export a ReactSelect.fuzzyFilter, or not. This allows you to eliminate the library-specific matchPos prop in exchange for something agnostic, much more flexible (better user-made fuzzy match, match/do not match non-ascii chars, blabla) and equally clean.

Abstraction 1

(If the above one sounds realistic)
Instead of the above, expose filterFunc as f(query): [String]. The function takes the query and returns a list of matches. This eliminates the seemingly necessary options props and gives you even more flexibility (dynamically changing list of options through if-elses in the callback). If you want to further reduce API surface, accept f(query): Promise [String], which is intended for async loading of options and/or match results. Kills asyncOptions.

Abstraction 2 (getting hardcore lol)

Built on top of either the original proposal or the previous one, if the latter makes sense. Say we use the latter. Change filterFunc to f(query): [ReactNode]. Solves #5. Solves potentially other styling issues that you'll otherwise need to expose as additional options (and it's hard to cover all the use-cases). Ultimate API would be f(query): Promise [ReactNode].

Perf concerns

Better perf tuning. The default is still the internal filterOptions. Except now the user will able to fine-tune it. E.g. smaller list? Use the best fuzzy match + frecency + levenshtein distance algorithm you got. Bigger list? Use a variation of default algorithm + caching.

Abstraction 1

Optional options caching is done by the user, by simply lifting the inline options list inside f into the upper scope (or use a transformer). Same for cached results. This isn't important; just mentioning it for completeness.

Abstraction 2

Allows user to use either classes or inline styles. Latter for API niceness, former for historical reasons or perf.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions