Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
created this issue from a note
in GOV.UK Design System Community Backlog
Jan 12, 2018
Current status of autocomplete work
Country picker consumes both accessible autocomplete and picker engine through
Feedback from @edwardhorsford suggests that the sorting and synonym logic in the picker engine is particularly coupled up with the country data and should stay as its own entity. Additionally, the picker engine has a jQuery dependency in Twitter's Bloodhound that it consumes.
We should therefore build the sorting and synonyms logic separately in accessible autocomplete.
We could look at the picker engine sorting functionality for ideas for sorting. It:
Each of these gives a score - we then sort by score by using a score, we can also have biases on some entries - which multiply the score this means that an entry with a bias of 2x (eg UK) will rise in the rankings, but not necessarily to the top, if it was only a very low score to begin with (thanks Ed!)
Here's an example (thanks Ed!) of what the current autocomplete without sorting logic does (only sorts alphabetically):
The example doesn't show synonyms but if we had them, it would make sense to rank canonical names higher than (potentially obscure) synonyms.
We should also test that the country picker that consumes accessible autocomplete remains functional.
What could be the MVP?
Features to discuss are:
We could also consider deprecating some existing functionality in accessible autocomplete (and potentially bring some of it back in at a later point):
Some examples of Accessible Autocomplete synomym logic that don't depend on jQuery
Should we continue to use Preact with the accessible autocomplete?
The current autocomplete imports Preact which is an alternative React, a library for building interactive UIs, and extends the Preact events.
My 2 cents:
I think an MVP should be as minimal as possible while giving value.
I think the results algorithm should be plug-in able if possible, so people can write their own if needed, or extend the default.
I think we need sorting, as otherwise very unexpected results can happen as seen in the gif in the comment above.
I don't think we need synonyms, weighting or typo fixing for an MVP - not all autocomplete use cases will need them.
Not sure why we would remove functionality that exists, unless there's a reason for removing them?
The deprecation suggestion was due to the fact that at the moment we are getting issues raised for things like the autocomplete not working with the latest version of React. It's good to support React if there's a need but as we're still trying to move out of the prototype phase I think we should probably focus our efforts for now on getting the core product working.