Also, @jgoux has been working on an AutoComplete UI independent implementation and might have some insight on how the Select component should be working.

@jgoux Would you mind sharing your plan for the Select and how we could join forces? Thanks!

Hi all and thanks Olivier for mentioning my little implementation. ^^

As I see it, there is 2 distincts components to add, the Select and the Autocomplete.

In my implementation I tried to do a little of both but I don't think it's a good idea.

The Select component should reflect the native select behaviour, so a value (or JS object) to chose against a provided list (+ optgroup support), plus a better UX.
For me the better UX could take the form of :

• A proper filter input (not the select input itself which couldn't be writable, but maybe an input at the top of the list, such as here)
• A way to unselect (cross icon (would require Input's support for suffixes) + a keyboard equivalence)
• A virtualized list (using react-virtualized which seems the most maintained/advanced solution right now) so we never pay the performance cost of passing large lists of objects.
• A possibility to pass any list of objects, not just the classic { value, text } (provided by default), so each user is free to customize how the data are processed (this means also provide hooks for the filter function)
• Supporting custom templates for the options

The Autocomplete component should reflect the native datalist behaviour, so a string only value which can be completed with the help of a list.
I'd have the same requirements for the list as for the Select with minor differences :

• No way to "unselect" as the end result should be a string, so emptying the field should be enough
• The filter is the input itself

For the async loading for both component, I'd provide an API to apply "loading" styles on these components but nothing more, I'd delegate the fetching / data providing to the user.
We could implement the loading as a progress bar in place of the Input component underline (so the implementation would be on the Input, and the Select/Autocomplete would just delegate). A loader centered on the list could also be a solution.

For the support of multiple selection, I'd write a totally separated component from the Select as the model and UX is quite diffrent and it would just complicate the code. We could always provide a single Select component to the users, but it could call one of SingleSelect/MultipleSelect implementations based on its multiple prop.

For the multiple selection design, I think the Chips component (https://material.angularjs.org/latest/demo/chips) could help. Isn't a MultipleSelect a more restricted version of Chips with a contrained list of values to pick from ?

I don't intend to submit a PR as the work has already begun here, but if you want to reuse part of mine don't hesitate!

Also I'm sure @Sharlaan would be happy to be involved 👍

Hey @jgoux thanks for joining in, I checked out your autocomplete/select demo and it looks very nice. The select didn't seem to be working yet but the autocomplete works well.

At this point, the SelectField behaves exactly like a native select component with two exceptions:

• the onChange handler has the signature onChange(event, value, index), but that can definitely change if needed
• the children can be of any type (including mixes of different types), right now I'm using MenuItem with a value prop. But you can also provide Input or dividers or whatever.

It sounds like the API you have in mind requires the user to pass a datalist or options prop that's an array of option objects. That makes the most sense if we want to control the options rendering internally and would let us use react-virtualized under the hood. However, I like the composability of letting the user provide children components themselves.

I just pushed a commit here with an example of a select that contains an Input that filters the options. It's not perfect but it demonstrates the power of letting the user define the list as children.

Anyways, I agree that multiple selection component should be separate from the single select component. They are very different UX-wise, especially if we want to use chips (I think we do).

Have you looked at https://github.com/JedWatson/react-select? I think we can borrow a lot of what's been done there. Maybe we can even bring it in as a dependency and style it to match? I haven't used it yet but it's very popular and already supports the features we want.

Which are the differences between a Select(multiple/single), a DropdownMenu, and an AutoComplete(besides its filter) that would justify implementing 3 or more distinct components ?
I think it's totally feasible to propose a single all-in-one component, with simple yet highly composable API, including with Chips or any customSelectionRenderer().
This is also less confusing for the user to choose which to use.

react-select is based on an options prop:

Options should be provided as an Array of Objects, each with a value and label property.

I think composable children would be better, especially in terms of styling where user could style his options nodes to his liking, which would require in react-select (and current Material-UI components) another separate prop dedicated to styling...
Only requirement would be to include within those children, detectable props like 'value' 'label'(for filtering) 'disabled' etc... or specific elements like <optgroups />.

Regarding integration of infinite datalist, i think it's feasible to integrate such libs with a children-based architecture. Here are 2 examples :

• one with react-infinite
• another with react-virtualized currently WIP with jgoux and bvaugh

Which are the differences between a Select(multiple/single), a DropdownMenu, and an AutoComplete(besides its filter) that would justify implementing 3 or more distinct components ?

They are very similar and they can certainly share some internals, here's my take:

• Select: an input in a form, limits a user to selecting one or more choices from a set of valid choices. Does not allow adding new choices, visually simple, choices are usually homogeneous in size, content, etc.
• Dropdown Menu: an expanding list of user actions with possibly more complex components embedded. Emphasis on actions instead of selection. Usually activated via a button or icon button instead of a text label.
• Autocomplete: also an input in a form but also useful for navigating long lists of actions/choices via upfront filtering. Basically an enhanced text input with real-time filtering of choices/suggestions. May allow the user to add new choices. Typically choices are homogeneous in size, content, etc.

Those are the typical descriptions and roles of each component, they're different but are built from the same basic components:

• Select: some sort of label with a dropdown Icon that activates a list of options
• Dropdown Menu: a button or icon that activates a list of buttons, labels, dividers, other inputs, nested menus, etc.
• Autocomplete: a text input with a dropdown icon, typing or clicking the button activates a list of filtered options

However, I don't think we need to worry about dropdown menus, they're already implemented well. I am making sure that whatever I build is also compatible outside of the select and autocomplete components. For example, a text input specially styled for embedding in a menu can be used with any of the components.

I think it's totally feasible to propose a single all-in-one component, with simple yet highly composable API, including with Chips or any customSelectionRenderer().
This is also less confusing for the user to choose which to use.

I think internally we can reuse components like MenuList, Input, FormControl, MenuItem, Chip, etc. which handle the majority of what we need but these three components are too different to be combined into one. I think it's more confusing to mix them together. For example, the Select component according to the Material Design spec needs to have the options menu popup over the input thus blocking it visually. However, the autocomplete needs to have the menu options anchor directly below the input so the user can continue typing.

We can make reasoning about which component to use by organizing the docs well and providing lots of examples. For example, an extensive forms doc that demos the select and autocomplete in different examples.

Only requirement would be to include within those children, detectable props like 'value' 'label'(for filtering) 'disabled' etc... or specific elements like .

I think this can be overcome by providing an Option, OptionGroup and other simple components that the user can either use directly (<Option value={1}>Label</Option>) or use to wrap more complex options (<Option value={1}><MyComplexComponent {...props} /></Option>).

Regarding integration of infinite datalist, i think it's feasible to integrate such libs with a children-based architecture. Here are 2 examples

Yeah I've come across your other library, I'll have to look at how you integrated with react-virtualized. Thanks for the input!

I think internally we can reuse components like MenuList, Input, FormControl, MenuItem, Chip, etc. which handle the majority of what we need but these three components are too different to be combined into one. I think it's more confusing to mix them together. For example, the Select component according to the Material Design spec needs to have the options menu popup over the input thus blocking it visually. However, the autocomplete needs to have the menu options anchor directly below the input so the user can continue typing.

I think this is where our opinions diverge :
this discussion has been made multiple times last year, and in one of them, someone came up with a simple wireframe nulling this argument. The concept is based on separating the input responsible for filtering from the input responsible for displaying selections, hence respecting the Material specs while exposing a filtering feature. After all, filtering is the menu responsibility, not the input's isnot it ?
I based my component on this wireframe and still continue adding features on top of its architecture without "confusion", except one : managing focus with keyboard on virtualized menu items, but this is offtopic XD.
So my question stands: which argument(s) justify Material-UI to expose 3 different components for more or less same features ? (and potentially all composed of same sub-components, ie ListItem, Popover, Input and InputLabel, the lowest ones basically, much easier to add features on top than say MenuItem, Menu and TextField)

We can make reasoning about which component to use by organizing the docs well and providing lots of examples. For example, an extensive forms doc that demos the select and autocomplete in different examples.

yes but -again- why not with the same single all-in-one component, each of these docs example showing different props and custom renderers setups ?
Also props documentation would be centralized. How many times i switched between SelectField, DropDownMenu, Menu, MenuItem, ListItem, List, AutoComplete docs to finally ending up reading the sources. One doc, One source = win ?

I think this can be overcome by providing an Option, OptionGroup and other simple components that the user can either use directly (Label) or use to wrap more complex options (<MyComplexComponent {...props} />).

Why not ? Personnally i leave this to user's imagination. ;)
For example jgoux in his example used styled-components (or JSS) to create his own <Option/>, and then injected them into the AutoComplete.

react-virtualized

Just a warning : i experienced much more difficulties to integrate with this lib than with react-infinite, but the author helped me.
However, it is much more friendlier in terms of focus handling (nothing to implement ;))
It also supports autodetection of children's height, which in the case of react-infinite, have to be injected manually.

Hope this help giving some insights ;)

I've been brewing over this for a few hours and I totally agree now... If we want to allow users to compose whatever they want, then they should be able to build a select, dropdown, autocomplete, or whatever using the same components that we provide.

As long as we make the most typical usecases easy to accomplish and document them we should be good.

So the obvious approach would be to provide some lower level components that can be assembled to build whatever a user imagines, and then provide a few pre-assembled versions for the most common usecases:

• Select: a M-UI replacement for the native select
• MultiSelect: a M-UI replacement for the native select with multiple selection
• Autocomplete: a M-UI replacement with better browser support for the native select/datalist
• Dropdown Menu: this is already done with the MenuList component

All we need to do is continue adding Menu/List compatible components and then assemble them together for the common usecase components above. A few new components that come to mind:

• MenuTextField: a wrapper around TextField with styling for use in a List/Menu and override to allow up/down arrows to move focus to other menu items
• Option: super simple component with value, selected, disabled, etc. props that replaces native option, also provides abstraction for multiple vs single selection. The same component is used for either type but will render differently.
• OptionGroup: has a label prop and wraps other components, probably just a specialized ListSubheader

So really, the big difference between select and autocomplete comes down to where the MenuList is anchored (below input for autocomplete, above the input and on the selected option for select), and which input is the "owner" (a read-only text-field for select, a text-field for autocomplete). But they share the same API for composing the menu, and for customizing how filtering works if enabled.

Just a warning : i experienced much more difficulties to integrate with this lib than with react-infinite, but the author helped me.
However, it is much more friendlier in terms of focus handling (nothing to implement ;))
It also supports autodetection of children's height, which in the case of react-infinite, have to be injected manually.

I haven't used either yet :) so I don't have a preference. If react-infinite is easier for our purposes I'll try it first. Maybe we can allow the user to pick which one they want to use by passing a prop? That might be too difficult to work out but I'll look into it.

Thanks for the all the info!

For info, i started composing with TextField + Menu and MenuItems, + react-infinite.

When i wanted to manage checkIcon customisation (especially positioning), MenuItem is rigid, so i went down to ListItem, preserving focus handling.

Next i wanted to propose multiple selection, but Menu seemed too rigid for this, so i went down to Popover and managed the selection logic on my own.
Also, there are 2 "visions" on how to deliver selection result(s):

• pass them up to parent right after cliking on some option
• store internally selections before passing them all at once after closing the menu
  ... while keeping the menu open. Can't do that with <Menu/>.
  Another reason is managing focus between the filter and 1st/last menu item. Menu doesnot allow this.
  Last reason is the menuFooter with custom buttons. I couldnot find a way to implement that with <Menu />.

For the filter, i found TextField were overkill and simply used Input (since it provides the UnderLine)

Next, i integrated react-infinite and lost focus handling with a filtered List. That's why i'm currently testing with react-virtualized which handles focus handling and infiniteList pretty easily. (WIP)

For the main container showing selections (when menu closed, according to Specs), i were initially using TextField for its UnderLine and floatingLabel. Here again i feel this might be overkill as well, and i'm experimenting with Input or simple div container + InputLabel/UnderLine. (WIP)

The implementation here is composed of Input, FormControl, InputLabel and the custom select input wrapper SelectFieldInput. The combo of InputLabel and a custom component passed to Input gets the styling and focus/blur perfect without needing a full TextField. I think that's probably the best way to go.

I built a demo here that has a restyled Input embedded in the options for filtering. Only issue is that it's a part of the options list so it's not stickied to the top... I'm not sure what the cleanest way to implement sticky header/footer controls is.

I haven't messed with the multiselect yet, so I haven't ran into issues with Menu being too rigid. Seems like we might need to go to List and Popover anyways to support both select and autocomplete.

Also, there are 2 "visions" on how to deliver selection result(s)

My vote is to provide two handlers: onChange which is fired after the menu is closed and the selection is finalized, and a separate onSelectChange that is fired after each item is selected/unselected. I think the common case is expecting the finalized result, but more advanced use might want deeper control.

Another reason is managing focus between the filter and 1st/last menu item. Menu doesnot allow this.

The demo I built with the embedded Input for filtering has this issue. When the menu is opened, focus is passed to the input container instead of the input itself which is weird...

i can help you with :

I built a demo here that has a restyled Input embedded in the options for filtering. Only issue is that it's a part of the options list so it's not stickied to the top... I'm not sure what the cleanest way to implement sticky header/footer controls is.

A simple idea would simply to NOT embed your filtering Input with options :

<Popover> // or Menu or List whatever
    <Input/> // filter
    {children} // those contain user's custom options
</Popover>

The demo I built with the embedded Input for filtering has this issue. When the menu is opened, focus is passed to the input container instead of the input itself which is weird...

Exact that's why i chose to implement my own "List" which is a simple div container exposing an onKeyDown handler managing the keypresses, and defaulting to the input inside Input (reactDOM.findDOMNode(this.InputRef).getElementByTagName('input'))

Also, there are 2 "visions" on how to deliver selection result(s)

My vote is to provide two handlers: onChange which is fired after the menu is closed and the selection is finalized, and a separate onSelectChange that is fired after each item is selected/unselected. I think the common case is expecting the finalized result, but more advanced use might want deeper control.

After i switched my onChange handler to the finalized-result-delivering behavior instead of my previous deliver-on-each-selection behavior, i got a long issue discussion with some user claiming the common behavior for onChange is actually deliver-on-each-selection.
So yeah 2 solutions:

• the one you already guessed with 2 different props onChange and onUpdate
• keep a single onChange prop but expose a 3rd parameter in signature
  onChange(event, selections, type) with type: PropType.oneOf(['UPDATE', 'FINAL'])
  Honestly i'm not sure which would be best for everyone...

Have you looked at https://github.com/JedWatson/react-select? I think we can borrow a lot of what's been done there. Maybe we can even bring it in as a dependency and style it to match? I haven't used it yet but it's very popular and already supports the features we want.

There is also a virtualized version : https://github.com/bvaughn/react-virtualized-select

If the API is sufficient to make an adapter for Material UI I'm all for it. 👍

Brian Vaughn went even further with react-virtualized-fast-filter but i would still check how to handle styling to Material-UI, dynamic row heights and focus before validating it.

@dummerbd Thanks for your contribution! 👍

Aside from a rebase, what's needed to move this forward?

I'm closing the PR as quite old now. Let's go back to the original issue #4792. Thanks everybody for your work. Any future work will definitely have to base on what have been discussed and experimented here 💯 .