[material-ui][Autocomplete] check for previousProps value being not-null after handling option click

[giulio-opal]

We were using an old beta version (@material-ui/lab) of Autocomplete in our codebase and after finally upgrading to v5 we noticed a regression in one of our components based on Autocomplete due to this line checking for previousProps.value.length while previousProps.value was null. I think this is the only place were previousProps.value.length is checked.

Context:

We probably do some weird hack in which we switch from a non-multiple to multiple autocomplete dropdown, this is because on first render, we populate the options with a list and then upon user selection, load another list and allow the user to select multiple values out of the dropdown.

Please let me know if there's any test I should be adding/modifying. Thank you!

• I have followed (at least) the PR section of the contributing guide.

[sai6855]

@giulio-opal can you provide sandbox which reproduces error you are describing?

[giulio-opal]

@giulio-opal can you provide sandbox which reproduces error you are describing?

Sorry for the slow turnaround, here's a codesandbox: https://codesandbox.io/p/sandbox/nervous-bush-lzzmfw
In short, if the data comes from a remote source, eg. through a query (in this case I've implemented it with timeout hooks), switching from single to multiple triggers this issue. This is a simplified version of our dropdown.

[ZeeshanTamboli]

We probably do some weird hack ...

So you shouldn't do this in your app in the first place?

[giulio-opal]

We probably do some weird hack ...

So you shouldn't do this in your app in the first place?

This null check is very hard to patch from our side, and our use of Autocomplete is very similar to the example provided, which should be straightforward.
There's no check in place for a nullable value for the reference to previousProps.

(The "weird hack" was mentioned because I hadn't isolated some additional tweaks that we do for UX purposes on Autocomplete, which then I did in the sandbox)

[ZeeshanTamboli]

But why do you switch from single to multiple autocomplete after user selection? Isn't this bad UX? Autocomplete should either allow single or multiple selections, not both. What's your use case for this? We want to avoid unnecessary code. The value type should remain consistent between rerenders.

[giulio-opal]

But why do you switch from single to multiple autocomplete after user selection? Isn't this bad UX? Autocomplete should either allow single or multiple selections, not both. What's your use case for this? We want to avoid unnecessary code. The value type should remain consistent between rerenders.

single -> user is offered some options to drill down to (eg. category)
multiple -> user can pick options within that category
single vs multiple helps us distinguish whether or not we should render checkboxes next to each option in the dropdown.

[ZeeshanTamboli]

I'm unsure about supporting the switch from single to multiple options in Autocomplete upon user selection. Can you add a test case first? I'll ask others to review it.

[ZeeshanTamboli]

Since this PR isn't active, I am closing it.