(WIP) RFC Choose react-component for base of TreeDropdownField / TreeMultiSelectField

[tractorcow]

See #6141 for context.

List of possible directions are listed below. This list will be updated as we find more solutions.

tree-select component

See https://github.com/react-component/tree-select

Demo at http://react-component.github.io/tree-select/examples/big-data.html

Pros:

• This component gives good out of the box support for tree rendering and searching, as well as multi-select functionality.

Cons:

• However, it doesn't have good accessibility (no keyboard navigation is available).
• Smaller user base
• Code quality

This library would be the easiest to get working, although it may be tricky to build in accessibility after the fact.

react-select component

See http://jedwatson.github.io/react-select/ (live demo)

Pros:

• This component is much closer in line with bootstrap look and feel, and is less visually dissimilar to the older chosen library.
• We could re-use this library in a much larger number of places (other select field components)
• Accessibility is built in and works well (keyboard navigation, aria tags).
• Large user base.

Cons:

• Tree view isn't a built in feature, and would need to be custom-built.

Looking at the designs previously mocked up, the final tree view could look like this:

jstree react

Not a solution in itself, but we could use this in tandem with either react-select, or a chosen-js react substitute.

https://github.com/alwinn1977/react-simple-jstree
https://github.com/chenglou/react-chosen

Pros:

• This solution most easily allows us to replicate our existing logic in react

Cons:

• This solution leaves us beholden to legacy issues; Rather than building something new we are re-implementing something that hasn't progressed in years.

iOS style drill down tree list

As no existing component exists with this functionality (in the reactJS world) we would probably need to either build this from scratch, or base it on react-select with heavy customisation.

[chillu]

More considerations (not requirements):

• Collision detection (drop up/down based on available space)
• Works on mobile browsers
• Can resize based on field container width
• Supports change detection
• Supports localisation (if it has any natural language text)
• Performant rendering of large lists
• Keyboard navigable
• Accessible
• Custom styling of list (e.g. "draft" labels for pages)
• Custom styling of results display (ellipsis in breadcrumbs)
• Lazy loading of long result lists
• Has good UX on mobile
• Works with Redux Forms
• Compatible with browsers we support
• Compatible license
• Search through full list values even if visible values are abbreviated (ellipsis)

[tractorcow]

Custom styling of results display (ellipsis in breadcrumbs)

we could simplify breadcrumbs to current level + back button to go up a level too (depth could be numeric indicator on button).

Another concern is search behaviour: We probably want to design for both basic navigation, and how the interface behaves when a search is active.

[sminnee]

Is this still relevant @tractorcow @chillu?

[chillu]

I've had a look through my "more considerations" list above, and think we've broadly got it covered. Any further search work is captured in #6842

@tractorcow Given we want to use this for groups selection in asset permissions, we need multi select as well, correct? Is that captured in a card yet?

[tractorcow]

We will eventually need multi-select, but it's more critical to implement this as a feature of a non-hierarchal list (ListBox) before we implement a TreeMultiselectField version. For instance we will need React Listbox for selecting members in a many_many relation.

[tractorcow]

Covered by #6145, which @sminnee said isn't beta1 . Do you want to change this priority?

[chillu]

Written up a broader card to replace #6145 (silverstripe/silverstripe-admin#52), and a separate card for potentially doing TreeMultiSelectField (silverstripe/silverstripe-admin#53). Which means we can close this one here.