TreeDropdownField - React Search Feature

[tractorcow]

Acceptance Criteria

• I can search for an item by partial title match
• I can find items quickly regardless of their nesting level
• I can determine when the search is still loading
• I can select an item in the result
• I can cancel a search in a user friendly way
• I can get context of where in the hierarchy a search result is related
• I can easily browse through dozens of search results
• The component is keyboard accessible and has correct accessibility hints

Tasks

• [x] store and retrieve the search term used
• [x] update tree field API to account for search, and showing in a flat list.
• [x] clear search when field no longer has focus
• [x] implement result item context display
• [x] Unit tests
• [x] Documentation
• [x] Design appropriate fields and add to CMS style guide (@clarkepaul)

Design

https://projects.invisionapp.com/boards/D3X68PS46K28/

Nice-to-have (?)

• [ ] Show full path for selected item (and remove Path field)

Out of scope

• Multiselect

Notes

• Broken out of https://github.com/silverstripe/silverstripe-framework/issues/6141
• Design pending for this component.

Related

• Use react-select for react-based dropdowns (SingleSelectField and MultiSelectField)
• Implement a TreeMultiSelectField in React

Pull requests

• [x] https://github.com/silverstripe/silverstripe-admin/pull/150
• [x] https://github.com/silverstripe/silverstripe-framework/pull/7167
• [x] https://github.com/silverstripe/silverstripe-asset-admin/pull/544

[clarkepaul]

@flamerohr I'd like to discuss what the UI looks like with this one as I haven't supplied any design since a long time and it looks like the direction has changed a fair bit.

[flamerohr]

@clarkepaul sounds good, I had wanted to touch base about the design soon too :)

[chillu]

@flamerohr Just a note that I think find-as-you-type is out of scope here (not in ACs), because it's very likely too slow in the current implementation. Also, please doublecheck that you've implemented all of the ACs, the tasks don't reflect stuff like keyboard accessibility.

@clarkepaul Where do you see the "stats" counters being used? If they're counting recursively, they're going to be resource intensive to create. And I don't see the need for them, given we have a flattened search now.

[flamerohr]

@chillu sorry, I'm not sure what you're referring to with "find-as-you-type"? Yes, I'm checking keyboard accessibility and other ACs, I didn't believe they warranted a task though

[clarkepaul]

@chillu they were already implemented in the POC so I did designs for them but since then @flamerohr and myself think it's mostly just clutter and isn't clear if its recursive results anyway, so we decided that it will be removed.