At the moment we do have wildcard abstractions for combobox UI pattern, but these abstraction are based on reach-ui combobox component Since reach-ui is no longer maintained https://github.com/reach/reach-ui/issues/972 there is no a clear way to contribute to reach-ui in order to improve combobox or other parts of reach-ui package.
For example, for combobox we do have one issue that may block us from using combobox widely in our app https://github.com/reach/reach-ui/issues/979. This is just one example of problems like this. We do have more of them but since Combobox UI doesn't expose enough API we can't fix them outside of Combobox UI.
In this issue we should fork or reimplement reach ui combobox in a way that it would be possible for us to support all missing features that Combobox at the moment doesn't have and can't have because of reach ui implementation.
Missing features
Persisting focus index over suggestion options
Custom keyboard navigation shortcuts
Custom open for extension highlight range logic
Support navigation over options with non unique values
Some functionality in the fuzzy finder that would be desirable to have in a shared combobox (and it might already be supported by the existing combobox):
Session-storage persisted query inputs and focus index.
Ctrl-n and Ctrl-p to cycle through items (browsers support this for URL suggestions).
Custom shortcut handler for tab/shift-tab to cycle between fuzzy tabs.
Ability to handle XXL size inputs (>400k elements). Repos like chromium/chromium have so many files and we still download all of the filenames and run it through the fuzzy finder. I estimate we could give millisecond latencies even for >1m items, but the initial download+indexing time might be slow (indexing could be done in the backend).
Ability to mix links (files/repos/symbols) and buttons (actions)
Not implemented by the fuzzy finder today, but I'd like to eventually display a preview for the active/highlighted item
Lazily computed URLs. The fuzzy finder only renders URL links for matches. The internal number of files may be 400k and it would be slow to materialize such a huge React element
Background
At the moment we do have wildcard abstractions for combobox UI pattern, but these abstraction are based on reach-ui combobox component Since reach-ui is no longer maintained https://github.com/reach/reach-ui/issues/972 there is no a clear way to contribute to reach-ui in order to improve combobox or other parts of reach-ui package.
For example, for combobox we do have one issue that may block us from using combobox widely in our app https://github.com/reach/reach-ui/issues/979. This is just one example of problems like this. We do have more of them but since Combobox UI doesn't expose enough API we can't fix them outside of Combobox UI.
In this issue we should fork or reimplement reach ui combobox in a way that it would be possible for us to support all missing features that Combobox at the moment doesn't have and can't have because of reach ui implementation.
Missing features
/cc @sourcegraph/frontend-platform