-
-
Notifications
You must be signed in to change notification settings - Fork 32.8k
[material-ui][Autocomplete] Improve design when there's a start adornment for small autocomplete #41781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[material-ui][Autocomplete] Improve design when there's a start adornment for small autocomplete #41781
Conversation
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Signed-off-by: Olivier Tassinari <[email protected]> Co-authored-by: Olivier Tassinari <[email protected]>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TahaRhidouani Thanks for the pull request. Left some questions above.
ZeeshanTamboli
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good mostly. Left few comments.
…m/TahaRhidouani/material-ui into autocomplete-startadornment-patch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @TahaRhidouani and @ZeeshanTamboli
…ment for small autocomplete (#41781) Co-authored-by: ZeeshanTamboli <[email protected]>
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:
