feat: add search to dropdown and multi-select fields

[gosiexon-zen]

Description

Added possibility to search in drop-down fields: Tagger and MultiSelect component. DropDown component is used only for system fields.

PR with translations: #758

Jira: GG-3415 & GG-3416

Screenshots

Screen.Recording.2026-02-13.at.12.00.05.mov

Checklist

• 📗 all commit messages follow the conventional commits standard
• ⬅️ changes are compatible with RTL direction
• ♿ Changes to the UI are tested for accessibility and compliant with WCAG 2.1.
• 📝 changes are tested in Chrome, Firefox, Safari and Edge
• 📱 changes are responsive and tested in mobile
• 👍 PR is approved by @zendesk/vikings

[gosiexon-zen]

It was to fix a Rollup build error. The @zendeskgarden/react-dropdowns.legacy package imports KEY_CODES from @zendeskgarden/container-utilities, but that export only exists in v1.x. Our package.json has @zendeskgarden/container-utilities at ^2.0.2 in dependencies, and v2.x removed the KEY_CODES export — so the legacy dropdowns package couldn't resolve it and the build failed.

• But this is already fixed in Melissa's PR: Remove legacy react dropdowns #751

[melzreal]

could you run yarn build and re-commit assets? currently shows a 91 thousand lines change

[Fredx87]

Some general comments:

Difference with Support

I noticed a couple of differences between this component and the one in support. It doesn't need to be exactly the same, but it would be nice to have some consistency.

In our case, the search results are presented "flat" (both for tagger and multiselect):

while in Support they are presented with the full path:

I think it is nicer to see the full path, since we also show it when an item is selected. It also nice that it highlights the search string

Second difference, when an item is selected from search in the Tagger component, we don't show it as selected when the user opens the combobox, in some cases we show a completely different set of options where the selected one is not visible (in this case "precision" is selected):

While support always show the right option as selected:

I think this is a big problem for a11y. for a screen reader user there is no way to know which option is currently selected.

There are also some differences in how we present things (search placeholder, no results, ...). This may be ok since are coherent with the lookup fields

Duplicated logic

There is a lot of duplicated logic in the two components around the search logic, like search state, filtered options, .... It would be better to consolidate it in a single hook, maybe even reusing the useNestedOptions hooks

No tests

There are no tests for the search logic and the components. It is true that we don't have tests for these two components right now, but we can take the opportunity to add them

Translation strings

Probably it is better to create a separate PR with the translations string only, so we avoid releasing this with untranslated strings

[Fredx87]

could you run yarn build and re-commit assets? currently shows a 91 thousand lines change

I said it countless time, but there is no need to commit the assets, they just create noise and also conflicts to resolve, without any benefit. The only helpful thing is the ability for others to test the branch without previewing locally, but I if I need to I just checkout the branch and run the preview

[pfemo]

I'm not exactly a typescript expert but how is the useFieldSearch being used?
I don't see it referenced anywhere?