Multi select component for ui-core

[ismay]

Our current <SelectField> component does not yet support the multiple attribute. We had a talk about how to build it on slack (see here)

Background info

• The native multi-select is not that accessible if you don't know how it works, as it needs a keypress to make multiple selections: https://jsfiddle.net/w8qznyc1
• A library that handles multi selects differently than native: https://harvesthq.github.io/chosen (not usable by us though, but a nice example)
• The material-ui multi select: https://material-ui.com/components/selects/#multiple-select
• And over there 👉, on the side, the Github multiselect (see assignees, labels)

In the talk, Joe asked:

I think that the decision needs to be made: are we staying strict native and adapting DHIS2 UI’s to that, or are we building something custom to DHIS2 needs? Once that decision is made I can work on a proper design spec in collab with you guys

Proposal

Personally I think that having the SelectField stay close to a native SelectField would be nice. It would keep the code and the component simple. My proposal would be this:

1. Allow a multiple attribute on our SelectField. That would then functionally make it work like the material-ui multi-select, which is closest to our current select-field, and works well I think (though an X on a chip to remove it might be nice).
2. For more complicated situations, like when you want filtering, searching, paging, I'd propose a different component, say a Combobox. Which is more dynamic, and has a searchfield, etc.

Obviously devs would have to be sensible and not use a SelectField with multiple for rendering 10000 items. That's where they'd need to use the ComboBox.

Let me know what you think if you want to partake in the amazing journey of the 📯Dhis2 Multiselect! 📯

[varl]

Allow a multiple attribute on our SelectField. That would then functionally make it work like the material-ui multi-select, which is closest to our current select-field, and works well I think (though an X on a chip to remove it might be nice).

Does this mean that we visually use the same SelectField as we do now, but every time an element is selected we add a Chip for it inside the SelectField box?

[Mohammer5]

Standard selects

I think it'd be nice to move away from select elements when using single selection. The UX can be terrible

Advantages of a native select

The native select has some advantages that I don't want to lose with a custom version

• Works with keyboard inputs when focused
• Works on mobile browsers

Disadvantages

• We can't style the options
• Doesn't work well with a lot of options
• We can't filter the options while keeping them visible
• Bad UX when having a lot of options

Another approach

The simplest version I think could be something like this also for single selection selects:

Advantages

• It would work both single- and multi-select.
• We can add any kind of UI around it
  • chips (for lists with 10k+ items)
  • Search field
  • etc.
• It's fairly easy to control the (max-)height and scrolling (overflow-y: auto)
• Display checkboxes (or an icon) to indicate multi-select
  • Or place a small (12px?) sentence above ("You can select multiple items")
• It works both on desktop and mobile browsers
  • We can choose whether we want to wrap white-spaces with a horizontal scrollbar or break options into multiple lines when too long
• Can be used for the group editor component that we'll have to create in ui-widgets

Disadvantages

• it will use more space vertically.

---

Also what @joe wanted to have shouldn't be a problem with this:

---

UPDATE:

I've talked to @ismay a bit, and it'd be nice to have the SelectFields style like I described above plus make it collapse-/expandable. We can also add resize: vertical.

Then users can adjust the size or hide it completely, whatever they're trying to do.
It can be quite nice to see the available options while editing another field (which can't be done with a normal select with single selection)

[ismay]

@cooper-joe I need this component in the scheduler-app and wouldn't mind implementing this. How do you feel about @Mohammer5's comment above? Is that something that would work for you? Maybe we need the eyes of the others on this as well before we move ahead?

[Mohammer5]

@ismay Please just create a jira issue and assign it to joe, set the one you're working on to 'blocked by' to express the urgency.

Like @cooper-joe has layed out in a comment in #60, that's the procedure we should follow in the future:

[ismay]

Sure, I’ll create the issue for tracking the work, but I assume @cooper-joe still needs an answer to the question he posed above before he can draft anything. And I assume it’d useful to have any comments before starting the design process.

[cooper-joe]

The 'Another approach' proposal laid out in @Mohammer5 's comment above looks good to me, it covers all requirements. I will work on the design specs this week so that @ismay can implement this while building the scheduler-app.

[varl]

@cooper-joe Then I think we should also use it for single select (Select component) instead of native, and replace the option HTML with an Option component.

[cooper-joe]

@varl Agreed. I'm working on the select as we speak, and to me it makes sense that the default component is a single select that can become much more feature-rich if you pass in multi for multiple selections, filter to add in a search field, and so on. But by default it would be a single select.

[ismay]

One thing that I'd prefer is if the multi select doesn't include extra features like filtering, etc. Basically, to keep it in ui-core and close to a native multi-select, but with better ux. I'd personally prefer to reserve the additional features for a separate, more complicated component that goes in ui-widgets. Not sure if the others feel that way or not?

[cooper-joe]

I propose we close this issue and continue discussion based on the initial designs here.