[select] Add Support typeahead when closed#48504
[select] Add Support typeahead when closed#48504atharva3333 wants to merge 6 commits intomui:masterfrom
Conversation
Deploy previewhttps://deploy-preview-48504--material-ui.netlify.app/ Bundle size
Check out the code infra dashboard for more information about this PR. |
| event.currentTarget.click(); | ||
| }; | ||
|
|
||
| const handleTypeaheadKeyDown = (event) => { |
There was a problem hiding this comment.
This creates a whole new self-contained chunk of typeahead logic that is inconsistent with the existing (open typeahead) behaviors, I don't think this PR is going in right direction overall @atharva3333
Also noticed it incorrectly makes disabled items and non-interactive subheaders in grouped selects candidates for typeahead.
There was a problem hiding this comment.
Could you clarify how you would prefer this issue to be approached?
Should the closed Select typeahead reuse/extend the existing MenuList typeahead behavior directly, rather than introducing separate matching/state logic inside SelectInput?
There was a problem hiding this comment.
I haven't thought about this too much yet
If you are still interested in working on this you could dig into the code a little deeper and use the original issue thread (not this PR) for questions/ideas etc
Should the closed Select typeahead reuse/extend the existing MenuList
Have you tried to or considered it yourself?
3 participants
fixes #48467
https://deploy-preview-48504--material-ui.netlify.app/material-ui/react-select/
Added tests to verify that typeahead keyboard navigation does not trigger when the Select is open, multiple, readOnly, or disabled. Also added coverage for matching, cycling, and timeout reset behavior.