Material-ui: [ SelectField ] [ Combobox ] Do you need a selectfield/combobox?

Created on 6 Aug 2017  路  14Comments  路  Source: mui-org/material-ui

I read your Contributing guideline, and it said to open an issue to ask if you'd be interested first. I worked on a component and I am using 'downshift' to try and make a reuseable combobox

https://codesandbox.io/s/QMGq4kAY

What are your plans for this? Would something like this work? ( v1.0.0-beta.4)

docs good first issue

Most helpful comment

@kybarg my example has been updated to the latest api today, which is the first release candidate, when @oliviertassinari pings me back about the listItem's selected prop (which I am using in this example) I will make a PR and get this in the docs. If 'menu' is the right way to go I can proceed that way, also.

I would be very happy to see this component properly abstracted and included in the Material UI core. Its something I need very much myself, personally.

All 14 comments

Hey, thanks for raising that point. Yes, I would love to see an integration example with downshift along side react-autosuggest in the documentation :).

Regarding sharing a wrapper around downshift, that's something we could do, but I'm worried about the endless list of features that people might require and that the implementation might not provide. We need low-level building blocks, that people can tear apart and twist.

This looks very nice, but I have a suggestion - the search shouldn't apply to the description IMO. What do you think?

@stavlocker , I only made an entry point so that the search could apply to whatever the enduser configures. For instance maybe you want to search 'names and emails' or 'just names' - you can override the search string. I agree for this example it might be more practical to search only titles, but I wanted to demonstrate that one could override that property.

Another (more real-world) example might be an object model where the firstname and last name are seperate properties, but you want a search box where users appear to be searching Doe, Jane, Jane Doe.
Imagine you get Json like this:

const people = [
  { firstname: 'Jane', lastname: 'Doe', age: 90},
  { firstname: 'Jonny', lastname: 'Smith', age: 9},
  { firstname: 'Ghengis', lastname: 'Khan', age: 9000},
]

So you're binding the combobox to a list of people, You can template like ${item.firstname} ${item.lastname}, really whatever you need. In this case you'd search across two properties. I find that in practice the ability to set a customize able search 'template' (rather than just a single property) is handy.

It makes sense if you check out around line 110 in the index.js file for the searchTemplate property.

Same reason I override the list item template, but also provide a default 'simple' list item.

In any case this was just a starting point, and I wanted to get some feedback about the interest in fleshing out a more-complete, more-reusable component (which I'd be happy to make, with tests and all that).

@oliviertassinari I am thinking of the semantic ui examples where they differentiate demos of core components and 'views' which are really just collections of components to make some recipe, like a 'comment' or a 'statistic'. Maybe this could be useful in the latter sense; I think that's what you are suggesting. Its goes in the docs, but maybe not in the core?

In any case, this was just a rough sketch to get the point across, and if there is a way this could be more useful, cool. I don't personally think it would be too much to depend on downshift for an 'official' combobox, mainly because downshift doesn't handle any of the ui, and only handles the autocomplete-y part. Its really just a collection of functions and some state management, basically. Its also very new so, I mean even if you did see some value in this, maybe wait a little for it to be out of beta, too. (If you are curious I'm also in a thread over on downshift about how to tighten up this implementation as well https://github.com/paypal/downshift/issues/94 )

I can tell you one thing I learned while making it that would be useful would be the ability to tell a list-item that it is 'active' from the list-item's api, by providing a property to it with a true. same with highlighted items. To achieve this I had to just pass in classes or set the style manually. This might be a practical thing for future tools that might need to set the state of list items via code.

At the very least I'd love to contribute to the docs, and list this as an example of integration: Do you want me to make a pull request for the docs?

@the-simian Good point, but still it should be default behaviour and configurable. Thank you for making this, it looks amazing!

@the-simian The autocomplete/select/dropdown topic is a large one! I think that we should go step by step. Ideally, I would see another demo alongside the react-autosuggest example.
Once we have both, we can start thinking about abstracting it away. But I would rather start with a low-level API and see how it goes.

downshift for an 'official' combobox

I agree. For instance, this is a dependency we could use for our DropdownButton component implementation.

useful would be the ability to tell a list-item that it is 'active' from the list-item's ap

That's something we have.

Do you want me to make a pull request for the docs?

I would love to 鉂わ笍 , you can follow the IntegrationAutosuggest.js as an example.

Ok thanks for the feedback @oliviertassinari , firstly, I am going to make sure I'm using the 'selected' property, and not using custom css (so I'm using the material components more correctly). Secondly, When I have the 'clearing' stuff tightened up and the downshift api has stabilized more, I'll make a PR to the docs.

Update; I made some progress this evening I am still working on this.

@oliviertassinari , is there a similar concept of selected for ListItems, or is that only available for menus? If so, can menu's in essence do the same thing as ListItems, or are they different?

Thank you for opening for me Downshift.
It is good alternative for my project while working on https://github.com/callemall/material-ui/pull/7632

@kybarg my example has been updated to the latest api today, which is the first release candidate, when @oliviertassinari pings me back about the listItem's selected prop (which I am using in this example) I will make a PR and get this in the docs. If 'menu' is the right way to go I can proceed that way, also.

I would be very happy to see this component properly abstracted and included in the Material UI core. Its something I need very much myself, personally.

hey wanted to follow up @oliviertassinari about the 'selected' property on the ListItems compared to the menu, do you know what the support there is? Is there plans to have it? It would be nice to have a 'highlighted' as well as 'selected' state.

@the-simian I would rather implement such feature on the MenuItem component, not the ListItem. But maybe there is use cases for both that I can't see.

A downshift demo was added with #9401. I'm closing the issue.

Was this page helpful?
0 / 5 - 0 ratings