Post author dropdown: add accessible search with debounced api request

[adamsilverstein]

Is your feature request related to a problem? Please describe.
When a large number of users are available as post authors, the select element does not scale well. A select element with thousands of users is unwieldy, difficult to use and may even crash the browser on lower powered devices.

Describe the solution you'd like
When a large number of users are present, I would like to see Gutenberg use an accessible select element, such as that provided by https://github.com/alphagov/accessible-autocomplete. With a small number of users, we can probably stick to a regular select element. See #5921.

Describe alternatives you've considered
I tried an implementation using react-select (http://jedwatson.github.io/react-select/), but discovered it is not accessible. I also tried an implementation using the Gutenberg's built in autocomplete component, but discovered the use case is different enough that it would require a significant reworking.

[gziolo]

I talked to @marcysutton at JSCOnf EU after she gave her excellent talk "Empathy Driven Development". More details on Twitter: https://twitter.com/marcysutton/status/1002870300936032256.

She recommended using autocomplete component for the use case we have. She mentioned that we should look at downshift which she helped to make fully accessible and see if it would fit. We can also find an alternative library or build our own based on the existing Dropdown.

[adamsilverstein]

@gziolo Wow, downshift looks really nice - thanks for sharing the link.

I previously took a pass at implementing this using a different accessible selector in #7385. I'll take a swing at a new PR using downshift.

[gziolo]

The closest demo to what we need from what I found:
http://downshift.netlify.com/?selectedKind=Examples&selectedStory=multiple&full=0&addons=1&stories=1&panelRight=0

[adamsilverstein]

@gziolo I took a pass at a downshift based implementation in #7478 - I could see how this could also be generalized to replace tag and possibly category selection, or even the block selector search which also needs to scale.

[gziolo]

That’s great. It looks like it wasn’t that difficult to integrate. I anticipate it’s going to be more work to shape data layer in a way it’s optimized for the best UX than to build the control itself.

[adamsilverstein]

Yes, the implementation was straightforward. We can alter the requests to include just the id and name and maybe slug for searching which is all we should really need.

[aduth]

I closed #15985 in favor of this issue. #15985 details the negative network impact of the current implementation, which would be resolved by proposal described here.

[noisysocks]

Noting that #7385 is where development for this is happening.

[swissspidy]

Since #23237 has been fixed, can this be closed?

[adamsilverstein]

Yep, closing.