(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.
(I understand if this isn't a big concern right now)
soushould probably matchSouth 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
filterFuncf(query, potentialMatch): bool, with a sane default being the current internalfilterOptions(maybe exported asReactSelect.defaultFilteror simply used as the default value offilterFunc). Fuzzy match libraries are available everywhere, but you can also export aReactSelect.fuzzyFilter, or not. This allows you to eliminate the library-specificmatchPosprop 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
filterFuncasf(query): [String]. The function takes the query and returns a list of matches. This eliminates the seemingly necessaryoptionsprops 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, acceptf(query): Promise [String], which is intended for async loading of options and/or match results. KillsasyncOptions.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
filterFunctof(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 bef(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
finto 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.