fix(UserSearchField): restore type-ahead broken by MUI v9 slotProps migration#1608
Conversation
…tmlInput slot
The MUI v9 slotProps migration handed each picker's renderInput TextField an
explicit `slotProps` object that only set the `input` (and `inputLabel`) slot.
An explicit `slotProps` prop replaces the one spread from `{...params}`, so this
dropped `params.slotProps.htmlInput` — the native <input> wiring (value,
onChange, keydown/focus handlers and the anchor ref from getInputProps). The
input was silently disconnected from the Autocomplete: keystrokes never reached
onInputChange, the search never fired and the suggestion list never opened.
Spread `...params.slotProps` into the explicit object so htmlInput survives, and
merge (instead of replace) the input/inputLabel slots. Restores the type-ahead
across UserSearchField (Add User / Add Team Member), UserShareSearch (share
modal picker), TeamSearchField and InputSearchField.
Add a regression test that types into the picker and asserts the search callback
fires and the matching option renders.
Signed-off-by: Lee Calcote <leecalcote@gmail.com>
There was a problem hiding this comment.
Code Review
This pull request updates several search field components to correctly spread params.slotProps into their underlying inputs, ensuring compatibility with MUI's controlled Autocomplete behavior. It also adds a regression test suite for UserSearchFieldInput to verify type-ahead functionality. The review feedback points out that overwriting endAdornment in UserSearchField discards default MUI adornments (like the dropdown arrow and clear button) and suggests merging them instead.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Pull request overview
This pull request restores MUI Autocomplete type-ahead behavior across several picker/search components by ensuring params.slotProps (including the critical htmlInput wiring) is preserved when passing an explicit slotProps object to TextField. It also adds a regression test to catch future regressions of this MUI v9 slotProps merge behavior.
Changes:
- Preserve Autocomplete input wiring by spreading
...params.slotPropsand merginginput/inputLabelslot overrides instead of replacing the whole object. - Apply the slotProps merge fix to User, Share-modal user picker, Team picker, and generic InputSearchField.
- Add a regression test asserting keystrokes trigger the search callback and that matching suggestions render.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/custom/UserSearchField/UserSearchFieldInput.tsx | Fixes TextField slotProps merging so Autocomplete htmlInput wiring isn’t dropped. |
| src/custom/UserSearchField/UserSearchFieldInput.test.tsx | Adds regression coverage for the restored type-ahead wiring (keystrokes + suggestions). |
| src/custom/UserSearchField/UserSearchField.tsx | Preserves Autocomplete wiring by spreading params.slotProps in the share-modal picker. |
| src/custom/InputSearchField/InputSearchField.tsx | Preserves Autocomplete wiring by spreading params.slotProps in the generic search field. |
| src/custom/DashboardWidgets/GettingStartedWidget/TeamSearchField.tsx | Preserves Autocomplete wiring by spreading params.slotProps in the team picker. |
Move the picker type-ahead regression test to src/__testing__ to match the repository's established test layout, and type its props via React.ComponentProps<typeof UserSearchField> instead of an `any` cast, selecting the input through Testing Library's combobox role. Signed-off-by: Lee Calcote <leecalcote@gmail.com>
Problem
Every user/team picker that offers a type-ahead — Add User, Add Team Member, the share-modal people picker, and the dashboard team picker — stopped suggesting as you type. The input still accepted text, but no search fired and the suggestion list never opened.
Root cause
The MUI v9
slotPropsmigration (b81e4dc) rewrote each picker'srenderInputto hand theTextFieldan explicitslotPropsobject:In MUI v9, the Autocomplete's
renderInputparams expose the native<input>wiring underparams.slotProps.htmlInput(thevalue/onChange/onKeyDown/focus handlers and the anchorreffromgetInputProps()), alongside theinputandinputLabelslots.A second
slotPropsprop replaces — it does not merge with — theslotPropsspread by{...params}. Because the explicit object only setinput(and sometimesinputLabel),params.slotProps.htmlInputwas dropped.TextFieldsources the native input props solely from that slot (inputProps: htmlInputProps←slotProps.htmlInput), so the field rendered a bare<input>with none of the Autocomplete's wiring: keystrokes never reachedonInputChange, the query never ran, and the listbox never opened.Fix
Spread
...params.slotPropsinto the explicit object sohtmlInputsurvives, and merge (rather than replace) theinput/inputLabelslots:Applied to all four affected pickers:
UserSearchField— Add User / Add Team MemberUserShareSearch— share-modal people pickerTeamSearchField— dashboard getting-started widgetInputSearchField— generic search fieldTest plan
UserSearchFieldInput.test.tsx— types into the picker and asserts the search callback fires with the typed value and the matching user renders in the suggestion list. Verified both assertions fail on the pre-fix code and pass after.npm run build(incl. DTS typecheck),eslint, andprettier --checkall clean.Downstream
@sistent/sistentconsumers (e.g. meshery-cloud, currently on^0.21.18) pick this up on the next published release + dependency bump.