[material-ui][Autocomplete] Custom end adornment placement differs from TextField

[stevepennings]

Steps to reproduce

Here's a sandbox of my 'bare-minimum implementation'.

Current behavior

Would it be possible to get the end adornment investigated with the 'standard' and 'filled' variant in mind? The spacing of the InputBase in the TextField is very different when wrapped in the Autocomplete.

If I miss something in my implementation, I'd be very grateful for support.

Expected behavior

The EndAdornment of the TextField having the same vertical placing as the EndAdornment of the Autocomplete.

Context

I've got a custom TextField component extending the TextField component of MUI. I'm trying to make the custom Textfield compatible with the Autocomplete of MUI. The 'filled' and 'standard' are surprisingly not behaving the same as 'outlined'.

Your environment

Search keywords: component:autocomplete

[steve-pennings]

Additionally I'd like to mention that the end adornment of the AutoComplete creates more padding once a value has been selected. When hovered the clear button shows itself <> hidden with the same padding. Consequently, the end adornment also ends up having odd spacing from the right when it's not hovered. Somehow I can't believe I'm the only one facing this issue, but I truly could not find similar issues. Apologies if there are...

[steve-pennings]

Just found this issue that may have something to do with this one:
#28465 (comment)

[DiegoAndai]

Hey, @steve-pennings. Thanks for the report, and sorry for the late reply.

As you mentioned, there's a difference between how the end adornment is handled in the TextField when inside Autocomplete. In this case, I recommend replacing the endAdornment completely and not relying on props.InputProps.endAdornment inside renderInput. Here's an example of what I mean that you can use as a workaround: https://codesandbox.io/p/sandbox/mui-autocomplete-textfield-filled-with-endadornment-forked-535q4g?file=%2Fsrc%2FApp.js

I believe there's room for improvement here, so the behavior is more consistent, so I'm adding it to the next major's milestone.

[steve-pennings]

Amazing, appreciate your reply and your workaround, thank you! Good luck with the next major milestone.

[TiagoPortfolio]

This solution still makes the end adornment overlap the clear icon

[DiegoAndai]

@TiagoPortfolio right, with the workaround, you would have to re-implement the clear icon. This is something to consider for the future proper solution.

[Nefcanto]

I also encountered this error. This is our Autocomplete look:

We want our Autocomplete to become a browsable field too (to open a full-featured list dialog with all filtering and sorting and searching capabilities to find and select and item).

Ths is our code:

                    renderInput={params => <TextField
                        {...params}
                        label={t(label)}
                        onBlur={() => {
                            if (!isDirty) {
                                setIsDirty(true)
                            }
                        }}
                        InputProps={{
                            ...additionalProps,
                            ...params.InputProps,
                            endAdornment: <>
                                {
                                    progress
                                        ?
                                        <Progress size={20} />
                                        :
                                        <BrowserIcons onCleared={() => {
                                            removeFilter(property)
                                            setSelectedEntity(null)
                                        }} />
                                }
                            </>,
                        }}
                    />
                    }

That workaround is a bad recommendation. Because it uses hardcoded values, we should be able to keep MUI theme values dynamically to be forward-compatible.