[Autocomplete] Remove startAfter feature

[dohomi]

The Autocomplete startAfter custom filter works only with the option freeSolo otherwise the Popper is shown with noOptionText until the minimum number is hit.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Showcase example with freeSolo
https://codesandbox.io/s/material-demo-e7oxj
Showcase example without freeSolo which seems buggy to me:
https://codesandbox.io/s/material-demo-t3my2

Expected Behavior 🤔

startAfter should work with or without freeSolo prop. It took me very long time to figure this out. Maybe otherwise it should be documented if this is the intended behaviour. Thanks!

Tech	Version
Material-UI	v4.9.10
React	latest
Browser	latest
TypeScript	latest

[oliviertassinari]

@dohomi Interesting, this sounds like a good reason to remove the startAfter option and to leave it to userland (custom filter + custom open/close logic). The initial request come from #19591.

[dohomi]

@oliviertassinari custom filter + open prop on autocomplete sounds reasonable.

[oliviertassinari]

@dohomi Thanks for the confirmation :). It feels that the frequency of the use case vs the added logic in the core doesn't worth it. If you want to submit a pull request to revert #19591, we would be happy to review it.

[marcosvega91]

@oliviertassinari maybe it can be a feature to keep and skip only in free solo mode, what do you think?

[oliviertassinari]

I have never really understood the motivation for the prop in the first place. It feels like a logic you put in place to save requests to the backend API, not something you do to help users. I would be in favor of keeping the autocomplete simple.

[marcosvega91]

If you want i can make a PR to remove the change

[oliviertassinari]

@marcosvega91 No objection from my side 😬

[dohomi]

@marcosvega91 the startAfter option works flawlessly on freeSolo. It would be a bummer if you revert the change without making it possible to get the same result in any other way.

[oliviertassinari]

@dohomi You can implement the same behavior by controlling the open state.

We have a usability issue when freeSolo={false} too. We don't give any feedback to the users that he needs to enter at least x chars. I think that in an acceptable version, we would display a "Need x more characters" message to guide the end-users. I think that it's better to leave it as a customization example.

[dohomi]

@oliviertassinari ok yeah - maybe best would be a demo example and leave it by the developer

[marcosvega91]

@dohomi You can implement the same behavior by controlling the open state.

We have a usability issue when freeSolo={false} too. We don't give any feedback to the users that he needs to enter at least x chars. I think that in an acceptable version, we would display a "Need x more characters" message to guide the end-users. I think that it's better to leave it as a customization example.

It sound's good but you need to change the behaviour of createFilterOptions because you need to access in some way to startAfter params inside useAutocomplete hook

[marcosvega91]

@oliviertassinari Can I implement this feature?

My idea is to change the return value of both createFilterOptions and useAutocomplete.
I will add CreateFilterOptionsConfig object type in the return value, in this way in Autocomplete component I can access to startAfter property and check if inputValue length is enough.

What you think?

[oliviertassinari]

@marcosvega91 Thanks for the proposal. I'm not sure to follow, which problem you aim to solve?

Regarding startAfter I think that we should move away from it, to focus on topics with a higher ROI. Regarding allowing custom labels in the popup, I believe we are already covered with the PaperComponent prop.

[marcosvega91]

@oliviertassinari solve the problem with !freesolo. Instead of show a message of "No options" I want to show a different message