[material-ui][Autocomplete] Improve design when there's a start adornment for small autocomplete

[TahaRhidouani]

Fix #41780

Changes

Makes the wrap behavior of the autocomplete the same as a textfield.

Before:

After:

Note: The flex: wrap is still used when the multiple prop 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:

[mui-bot]

Netlify deploy preview

https://deploy-preview-41781--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against b958bea

[ZeeshanTamboli]

@TahaRhidouani Thanks for the pull request. Left some questions above.

[ZeeshanTamboli]

Looks good mostly. Left few comments.

[ZeeshanTamboli]

@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 ownerState in this case. The conditional application of styles using ownerState was eliminated in [Autocomplete] Convert to support CSS extraction #40330, and theme variants were employed to facilitate CSS extraction. However, the advantage of utilizing ownerState is that it eliminates the need for introducing a new class.
• In this PR, the application of the flex-wrap style when multiple is true introduced a new multiple class. 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-wrap style when multiple is true as done in [Autocomplete] Convert to support CSS extraction #40330. This eliminates the need for introducing a new multiple class 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

[DiegoAndai]

Hey @ZeeshanTamboli and @TahaRhidouani!

So, what's the optimal choice here?

I'm not against a multiple class, but it should be applied to the root and not inputRoot. Applying it to inputRoot is helpful for this use case, but it would be inconsistent. So, if we were to use classes, the correct styleOverrides usage would be

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 multiple class.

[ZeeshanTamboli]

@DiegoAndai Since this PR has been open for a while, I made the changes myself to use variants. I've also included a visual regression test - https://app.argos-ci.com/mui/material-ui/builds/27693/89392040. Could you review?

[DiegoAndai]

Thanks for working on this @TahaRhidouani and @ZeeshanTamboli