<AutocompleteInput> should allow to override renderInput

[ibraym]

The SelectInput component currently lacks support for grouping options, a feature that is available in the AutoCompleteInput component.

The challenge arises because the AutoCompleteInput component input must be a string, making it incompatible with rendering custom components, which the SelectInput component supports.

This limitation creates a gap in functionality:

If grouping is required, AutoCompleteInput must be used, but it sacrifices the flexibility of rendering custom components for displaying the selected option. Conversely, SelectInput can render custom components but does not support grouping.

[slax57]

I believe the AutocompleteInput component does also accept a React Element as optionText, just like SelectInput, which makes it possible to render a custom component for the selected option.
Can you give it a try?
https://marmelab.com/react-admin/AutocompleteInput.html#optiontext

[ibraym]

The gap in functionality is in a case where we need grouping and displaying selected option as custom component.

I do use optionText to render a custom component for the options list. But in AutocompleteInput we must also pass a function as the inputText prop to render the selected option as the underlying Material UI component requires that the current selection is a string. https://marmelab.com/react-admin/AutocompleteInput.html#using-a-custom-element-for-options

In the following, we use custom component for options with grouping. But after making a selection, the selected option must be displayed as a string.

We can display the selected option as a custom component using SelectInput but grouping options is not supported.

[slax57]

You're right. Thanks for the clarifications.

It seems that MUI handles grouping in a very different way between Autocomplete and Select.

Supporting grouping in <SelectInput> would require a more complex logic, as it's not simply a single prop to forward as it's the case for <AutocompleteInput>.
So, this is probably doable, but a bit more complex.

An alternative solution could be to let you customize the rendered input in <AutocompleteInput>.
I've done some tests, and it turns out you can already customize it by passing your own renderInput prop to <AutocompleteInput>.
Currently TS is complaining about the renderInput prop not existing on <AutocompleteInput>, but I see no good reason why we omitted the renderInput prop from <AutocompleteInput>. We could update the TS type to allow it.

Can you confirm passing your own renderInput to <AutocompleteInput> allows to solve your issue?

Thanks.

[ibraym]

I solved it using TextFieldProps and startAdornment for single selection, for multiple selections we should use renderTags.

return (selectedChoices && selectedChoices[0]) ? (
    <RAAutocompleteInput
        TextFieldProps={{
            InputProps: {
                startAdornment: (renderStartAdornment) ?
                    renderStartAdornment(selectedChoices[0]) : null,
            },
        }}
        {...rest}
    />
) : (
    <RAAutocompleteInput
        {...rest}
    />
);

Passing a custom component using renderInput could solve it, but we still need to render an input in the custom componen to be able to select another option.

I suggest not omitting renderInput and renderTags props from AutocompleteInput to give the user the freedom to provide its own component.

[slax57]

Thanks for your feedback and for sharing your solution.

I don't believe renderTags is omitted (you should already be able to override it), but I agree we should not omit renderInput in the TS type.

Marking as a (TS) enhancement.