[material-ui][Autocomplete] Improve design when there's a start adornment for small autocomplete#41781
[material-ui][Autocomplete] Improve design when there's a start adornment for small autocomplete#41781ZeeshanTamboli merged 35 commits intomui:nextfrom TahaRhidouani:autocomplete-startadornment-patch
Conversation
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Signed-off-by: Olivier Tassinari <olivier.tassinari@gmail.com> Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
Netlify deploy previewhttps://deploy-preview-41781--material-ui.netlify.app/ Bundle size reportDetails of bundle changes (Toolpad) |
…idouani/material-ui into autocomplete-startadornment-patch
ZeeshanTamboli
left a comment
There was a problem hiding this comment.
@TahaRhidouani Thanks for the pull request. Left some questions above.
ZeeshanTamboli
left a comment
There was a problem hiding this comment.
Looks good mostly. Left few comments.
…m/TahaRhidouani/material-ui into autocomplete-startadornment-patch
There was a problem hiding this comment.
@TahaRhidouani I've made some tweaks in the theme overrides test, and the implementation we have here resolves the issue. Thanks for your contribution.
However, now that we aim to support CSS extraction, I'm uncertain about the correct and preferred approach. The current method, introducing a new multiple class, will be compatible with CSS extraction when Pigment CSS is used, as we haven't utilized ownerState here but increases bundle size slightly.
I'm unsure about the definitive approach.
This discussion pertains specifically to the flex-wrap style when Autocomplete has the multiple prop.
Here are some points to consider:
- We didn't employ
ownerStatein this case. The conditional application of styles usingownerStatewas eliminated in #40330, and themevariantswere employed to facilitate CSS extraction. However, the advantage of utilizingownerStateis that it eliminates the need for introducing a new class. - In this PR, the application of the
flex-wrapstyle whenmultipleis true introduced a newmultipleclass. This may lead to increased HTML bloating and a slight increase in bundle size for the already hefty Autocomplete component. Nevertheless, this approach will support CSS extraction using Pigment CSS. - We could utilize theme variants and apply the
flex-wrapstyle whenmultipleis true as done in #40330. This eliminates the need for introducing a newmultipleclass and also supports CSS extraction. However, there's a downside to overriding via theme as shown below.
Regarding point 3, with the current solution developers could directly do (as shown in the test):
const theme = createTheme({
components: {
MuiAutocomplete: {
styleOverrides: {
multiple: {
padding: '15px',
},
},
},
},
});With theme variants developers will have to target the inputRoot class:
const theme = createTheme({
components: {
MuiAutocomplete: {
variants: [
{
props: { multiple: true },
style: {
[`& .${autocompleteClasses.inputRoot}`]: {
flexWrap: 'no-wrap',
},
},
},
],
},
},
});Developers need to be educated to target inputRoot here whereas in styleOverrides above they can directly target multiple class because we resolve it in overridesResolver:
{
[`& .${autocompleteClasses.inputRoot}`]: {
[`&.${autocompleteClasses.multiple}`]: multiple && styles.multiple,
},
},So, what's the optimal choice here? @DiegoAndai
|
Hey @ZeeshanTamboli and @TahaRhidouani!
I'm not against a const theme = createTheme({
components: {
MuiAutocomplete: {
styleOverrides: {
multiple: {
[`& .${autocompleteClasses.inputRoot}`]: {
flexWrap: 'no-wrap',
},
},
},
},
},
});Which is similar to what we would have by using a theme variant. So, to answer the question, both using classes or theme variants are valid options. The ideal path IMO is to use theme variants in this PR, and have a separate PR adding the |
|
@DiegoAndai Since this PR has been open for a while, I made the changes myself to use |
DiegoAndai
left a comment
There was a problem hiding this comment.
Thanks for working on this @TahaRhidouani and @ZeeshanTamboli
…ment for small autocomplete (#41781) Co-authored-by: ZeeshanTamboli <zeeshan.tamboli@gmail.com>
Fix #41780
Changes
Makes the wrap behavior of the autocomplete the same as a textfield.
Before:

After:

Note: The
flex: wrapis still used when themultipleprop is enabled on the autocomplete to wrap the chips over multiple lines.Prevent the clear icon from colliding over the input text when hovering
Before:

After:
