[AutoComplete] does not update displayed value if options are received after the value

Balour commented 2 years ago

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯

An autocomplete who has its options given to it after the value, does not update its displayed value, even though getOptionLabel returns the right value

Expected behavior 🤔

The displayed value should reflect the getOptionLabel function

Steps to reproduce 🕹

https://codesandbox.io/s/autcomplete-wrong-value-displayed-when-options-arrive-after-value-b9kkvm?file=/src/autocomplete.js

Steps:

Open page, information about object is fetched and set
Options are fetched and tend to arrive after the information about the object
Options are set and given to AutoComplete
AutoComplete displays initial value instead updating to the result of getOptionLabel

If we swap the delays and make the information about the object arrive after the options, the correct value is displayed. getOptionLabel returns the correct value at all times. The value is updated when interacting with the field

Context 🔦

It is technically a duplicate of #25096 (which I opened last year) but we just got around to upgrading to MUI 5 last week (in part hoping to have this fixed as noted in #27313) but after tests, the issue persists. After digging, I saw that this pull request did a regression discussed in #28098 and an additional fix was done.

Long story short, the reported behavior is still incorrect for us. getOptionLabel returns the right value but the initial value is displayed incorrectly on load of the page

Is there a way to force a value update? Any workaround?

Your environment 🌎

npx @mui/envinfo

``` System: OS: Windows 10 10.0.19044 Binaries: Node: 16.15.1 - C:\Program Files\nodejs\node.EXE Yarn: Not Found npm: 8.13.2 - ~\Desktop\isovision-web-ui-mui5\node_modules\.bin\npm.CMD Browsers: Chrome: 103.0.5060.114 Edge: Spartan (44.19041.1266.0), Chromium (103.0.1264.37) npmPackages: @emotion/react: ^11.9.3 => 11.9.3 @emotion/styled: ^11.9.3 => 11.9.3 @mui/base: 5.0.0-alpha.87 @mui/icons-material: ^5.8.4 => 5.8.4 @mui/lab: ^5.0.0-alpha.88 => 5.0.0-alpha.88 @mui/material: ^5.8.6 => 5.8.6 @mui/private-theming: 5.8.6 @mui/styled-engine: 5.8.0 @mui/styles: ^5.8.6 => 5.8.6 @mui/system: 5.8.6 @mui/types: 7.1.4 @mui/utils: 5.8.6 @mui/x-date-pickers: ^5.0.0-alpha.7 => 5.0.0-alpha.7 @types/react: 17.0.47 react: ^17.0.2 => 17.0.2 react-dom: ^17.0.2 => 17.0.2 typescript: 4.7.4 ```

mnajdova commented 2 years ago

Thanks for the report and the history shared around the issue. It seems to be related to the freeSolo variant of the Autocomplete. I would ask if you can simplify the codesandbox with the code that is only relevant to this issue, otherwise it is really hard to debug what changes where. I am asking this because I tried playing a bit with the autocompletes provided and they kept crashing, for example if I clear the text in the autocomplete.

One additional question. In the example you provided you are using the Autocomplete in controlled mode, which may be one of the reasons why the value is not changed, you would need to react to the changes of the options.

Balour commented 2 years ago

I will trim it down it's no problem, I had already started so but thought it was stable. I will get it back closer to the example in the documentation (which this was based off of originally)

As for controlled mode, I'm not sure what action needs to be taken when receiving the options, other than passing them to the component?

Balour commented 2 years ago

I have updated the sandbox (forked) and used the material-ui Autocomplete example (freeSolo - creatable) as my base in this case https://codesandbox.io/s/autcomplete-wrong-value-displayed-when-options-arrive-after-value-forked-s9vmy4?file=/src/autocomplete.js

The main differences are: state outside of the component, controlled by the parent
Added "imdbID" to the films (corresponds to the url id when visiting the page of the film) to have a similar structure to our needs
Changed the getOptionLabel around to check for objects first and not string as we have our value saved as string so we need to check if we have the object first and then if not, it's a created string

Let me know if I can help in any way

Thank you for your time

mnajdova commented 2 years ago

We are not invoking onChange if the options change, and in my opinion this is correct behavior (as there wasn't any interaction with the component). I would assume you can wait for all promises to resolve before setting the value, this way it should work as expected.

Balour commented 1 year ago

Confirmed as working in my use case, thanks

mui / material-ui