Material-ui: [Autocomplete] Provide a simple abstracted implementation

[mysticwukado]

As everyone know, current version of mui autocomplete is complex and heavy. Is there a way to somehow inject the previous version of mui autocomplete and use with v1? I love all the features of v1 except that autocomplete.

Anyways

• did you guys think about making two autocomplete's, so users can choose which of them to use?
• Autocomplete - heavy, new machine which requires external libraries
• Lightweight autocomplete - light version of autocomplete from the previous version of mui

Thanks! :+1:

[mbrookes]

You can follow the migration guide to use both versions concurrently.

[oliviertassinari]

@mysticwukado We can't compete with already well implemented generic solutions like react-select, react-autosuggest and downshift. We will do a service to the JavaScript ecosystem not shipping our own version.
What we can always do is abstracting a style override on top of them for quick usage. However, before looking into it. I want to add a third override example with react-select.

[mysticwukado]

@oliviertassinari I got your point. However - my bundle is so heavy enough atm that I just can't afford another library just to handle the autocomplete.

@mbrookes What about bundle size? If I use both version? Will it grow up two times?

[mbrookes]

@mysticwukado No, just by the size of the v0 Autocomplete and its dependencies, but you may well find that's more than the size of v1 autocomplete plus external library.

[mysticwukado]

@mbrookes Thank you, thanks for an amazing library :)

[jgoux]

I wish there was a Select provided by material-ui which can compete with all the features Vuetify's select provides : https://next.vuetifyjs.com/en/components/selects

I agree it should be built using established libraries like downshift, but the abstraction and all the plumbing should be hidden from end user of mui.

[oliviertassinari]

I have done a new iteration on the Autocomplete answer of Material-UI: #10070. There is no plan to add an Autocomplete component for the first release of v1. We will see later. We have other priorities.

[jgoux]

I just wanted to add that this project https://github.com/techniq/mui-downshift looks promising and exactly in the scope!

[oliviertassinari]

I'm adding this issue to the priority list for post v1. I agree. The community needs a simple component for 80% of the use cases. https://twitter.com/kentcdodds/status/958813204628504576

[igorbt]

@oliviertassinari , I needed to implement a simple Autocomplete, but was too lazy to follow the suggestions from the docs (after one of my colleague had a hard time actually using one of the third party libraries you suggested). So I came up with a simple solution with no dependencies, just Material UI components: https://codesandbox.io/s/zxknv9r8w4 . If you think it's worth it, maybe we can put it into docs as a suggestion.

[mbrookes]

@igorbt It's a good start (for short in-memory lists), but it doesn't currently support keyboard navigation which is crucial.

[igorbt]

@mbrookes, you're right. Plus there are some more problems to solve with my implementation, like scrolling the list with mouse, setState with input value triggered before the setState with value from dropdown. It could became a non-trivial component when fixing all these. Still I would like an Autocomplete MVP to be implemented in Material UI, just for the 80% of the cases.

[mbrookes]

@igorbt An example of that is significantly incomplete isn't a good example. Now you can see why we lean on 3rd-party integrations. 😄

As an example, the original implementation of SpeedDial was a written as a docs demo of about this level of complexity (it was the simplest way to test the concept). Turning it into something "lab-ready" (not even production) was an order of magnitude more work.

You're welcome to submit a more complete version, either as a fully worked-demo, or complete lab component, but I can't see us including it in the docs in its current form. Thanks for sharing it though.

[oliviertassinari]

I'm closing for #13863. I believe it's the same concern.