New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[useAutocomplete] Add support for groupedOptions
to always be returned regardless of focus
#269
Comments
@martin-slalom I'm having trouble understanding your issue. Your CodeSandbox example, although somewhat unclear, doesn't seem to be behaving as you described. If the list isn't being shown and the input isn't focused, why do you require |
@ZeeshanTamboli For a "traditional" autocomplete I 100% agree with you that the listbox should only be rendered when My feature request is to add a prop that could be toggled on to give the developer the ability to overwrite that resetting to "[]" so that they may utilize the hook in non-traditional ways. |
If you're not building an autocomplete feature, it's best not to utilize the I don't believe we'll add a prop for this. It doesn't seem necessary to me. I'm closing this issue. |
So the thing is @ZeeshanTamboli my feature is functionally an autocomplete in every regard. It's just not visually a "traditional autocomplete" where the dropdown is triggered by focusing an input, rather the input and dropdown live together in a popover that's triggered by the clicking another element. It has the same need for everything that a traditional autocomplete would would have EXCEPT the clearing of the dropdown list once the input loses focus. I'm confused how that is not shown via my example, could you please explain how the component in the codesandbox is not an autocomplete? Additionally, focusing the input programmatically when the popup is opened does work until you use the "tab" functionality to select an item from the list since at that point the input would loose focus for that of the list item button, as you can see in the example. |
In the autocomplete, we use the combobox W3 ARIA pattern. According to this pattern, the popover is hidden by default and requires a trigger to be opened. |
I feel like my example/use case still follows that pattern as well, the popover/list is hidden by default and exposed via a trigger as well. It's just that trigger in this case isn't an input it's a div. The user can filter the list via typing in the input, "hover" over options via arrow/tab keys, and selecting one by clicking or pressing enter. Other features like list grouping can also be used. Maybe there's some confusion, especially since the tag is "component:Autocomplete", I'm not suggesting any changes to the Mui Autocomplete component. I'm merely suggesting an enhancement to the My requested change would have no effect at all on the Mui Autocomplete at all. It would only add flexibility/functionality to |
Both Material UI's Autocomplete and Joy UI's Autocomplete utilize the
Okay, I noticed the following statement in the ARIA docs as well: |
Additionally, please keep in mind that the |
So should I open a PR against the Base-UI repo as well as Material-ui repo? |
You can open it only in the Base UI repo. Version 1 of Base UI is coming soon, and the Base UI-related code will be removed from the Material UI repo. |
Summary
I have a need to build my own autocomplete that renders the groupedOptions/list options and the input in a single popover. The only issue I'm running into with
useAutocomplete
to build out this component out is that thegroupedOptions
is changed to an empty array when the input is no longer focused. My proposal would be to add a prop to the useAutocomplete that would override this functionality to allow the list to be rendered regardless of the input being focused. This would give the developer more freedom to build out the dropdown list.Examples
Example use case, I need to create an account selector that shows the Currently selected account but when you click the name it opens a Popover with a search input and the list of accounts. As the user types it filters and acts just like the autocomplete where the user can select a value and it will then navigate them.
I've thrown together, a very rough, example of this. You'll notice that when you click "The Godfather" in the blue bar a popover opens and the list reads "no results". This is because the input isn't focused, then when the input is focused the list appears. We can set
autoFocus
on the input and setopenOnFocus
on the useAutocomplete however, when the user selects an option from the list the focus is then changed to that item, away from the input and thus the list closes (reverting to "no results").I propose an "override" prop on the
useAutocomplete
component to give the developer freedom to receive the list without worrying about the focus state of the input.Motivation
No response
Search keywords: useAutocomplete
The text was updated successfully, but these errors were encountered: