[Autocomplete] Add an option to not resetInputValue on selectNewValue

[binh1298]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Summary 💡

Currently, the autocomplete behaves like this:

1. Given an Autocomplete
2. When the user types in a keyword to search
3. And the user select an option
4. Then the keyword is deleted

I believe this is because of this line

material-ui/packages/mui-base/src/AutocompleteUnstyled/useAutocomplete.js

Line 678 in 684cd85

resetInputValue(event, newValue);

I was hoping for an option for me to edit that line such as

if (clearOnSelect) resetInputValue(event, newValue);

Examples 🌈

I was able to make a workaround like this, but I think this can be dangerous because I'm not sure what can trigger the "reset" event.

https://codesandbox.io/s/long-monad-8l0nrm?file=/demo.tsx

export default function LimitTags() {
  const [inputText, setInputText] = React.useState<string>("");

  return (
    <Autocomplete
      inputValue={inputText}
      onInputChange={(_, value, reason) => {
        if (reason === "reset") return;

        setInputText(value);
      }}

Motivation 🔦

Our designers asked if we can do this and I do think this can be helpful.

[michaldudak]

The "reset" event is triggered in the following cases:

• whenever a new value is selected
• on blur, when the clearOnBlur prop is set
• the value prop changes (in case of a controlled component)

Instead of adding yet another prop to control the behavior, I'm more inclined to expose a state reducer that will allow a much greater degree of control over the internals of the autocomplete. This, however, is a significant change. We're planning to overhaul the useAutocomplete logic, so I'll try to include this in this effort. I can't commit to any timeframes, though.

[nicolas-ot]

Instead of adding yet another prop to control the behavior, I'm more inclined to expose a state reducer that will allow a much greater degree of control over the internals of the autocomplete. This, however, is a significant change. We're planning to overhaul the useAutocomplete logic, so I'll try to include this in this effort. I can't commit to any timeframes, though.

Would it be a good idea to first add a new prop (I think, clearOnSelect) to solve this issue? If yes, then I'm going to work on this issue.

[oliviertassinari]

From what I understand:

Problem

I was able to make a workaround like this, but I think this can be dangerous because I'm not sure what can trigger the "reset" event.

How to solve this

At a high level, we need to give more granularity to the events to disambiguate.

Options

1. In [Autocomplete] Provide more details in the onChange event #19064, we added more details on the change events precisely so that developers could control the input value and have custom logic. We can continue doing more, we have the reason for the onChange event, we could propagate it to the onInputChange too:

diff --git a/packages/mui-base/src/useAutocomplete/useAutocomplete.js b/packages/mui-base/src/useAutocomplete/useAutocomplete.js
index 8af5d5cbec..4dd54ba584 100644
--- a/packages/mui-base/src/useAutocomplete/useAutocomplete.js
+++ b/packages/mui-base/src/useAutocomplete/useAutocomplete.js
@@ -682,7 +682,7 @@ export default function useAutocomplete(props) {
       }
     }

-    resetInputValue(event, newValue);
+    resetInputValue(event, newValue, reasonProp);

     handleValue(event, newValue, reason, { option });
     if (!disableCloseOnSelect && (!event || (!event.ctrlKey && !event.metaKey))) {

2. The proposal of @michaldudak, which sounds like the same path as in https://github.com/downshift-js/downshift#statechangetypes, and also seems to be the same high-level change as 1. with a different API.

3. Adding a new prop: ❌ dead end, unless there is a clear signal that this is a frequent use case (we don't seem to have it).

I think that 1. could be good enough, and aligned with the current API. It's probably a breaking change though, as what used to be "1 reason" would turn into "X reasons" based on the case.
I think that 2. can solve the problem as well, but it feels like it's not directly related to this problem.

[binh1298]

hi @oliviertassinari can you help me review this PR?