The DST tentatively agreed that this task shouldn't be considered a blocker for the first release of Codex's TypeaheadSearch. We'll have to decide whether the improvement should be implemented by Codex (e.g. include a slot in menuItem) or handled by the application.

Removing WVUI with TypeaheadSearch now building on top of Codex and T310243.

@Jdlrobson @TJones — what is needed in order to make this change? Is there Search API stuff that needs to be changed, or is it mostly client/front-end work? cc @ovasileva @ldelench_wmf

In T303013#8255700, @alexhollender_WMF wrote:

@Jdlrobson @TJones — what is needed in order to make this change? Is there Search API stuff that needs to be changed, or is it mostly client/front-end work? cc @ovasileva @ldelench_wmf

Sorry, I don't know. I'm not familiar with the implementation plan. If whoever is doing the implementation needs help with the API or other implementation details, they can come talk to the Search team.

This is purely a Codex task at this point for the design systems team (with assistance from web team).

The API currently returns matchedTitle field to significant a redirect: https://en.wikipedia.org/w/rest.php/v1/search/title?q=Corn&limit=10 so I don't think any API changes are needed at this point. The TypeaheadSearch component would need an update to support an optional title annotation field at which point Vector would be able to pass in the content in the brackets.

The TypeaheadSearch component would need an update to support an optional title annotation field at which point Vector would be able to pass in the content in the brackets.

This sounds sensible to me. In the context of the WiKit Design System, we encountered a similar scenario where we needed to indicate extra information about particular suggestions in the Lookup component. We decided to make room for these labels in the component configuration:

From a system's perspective, we should decide whether the potential new slot should live in TypeaheadSearch or maybe (in order to cover further use cases) the MenuItem component.

The component spec sheet for the menu item with supporting text has been created in T323987 and it's ready to be implemented in Codex.

Moving this to "following" since we are completing the Codex part (T323987) but likely won't implementing supporting text for redirects in Vector (this task).

@ovasileva @Jdlrobson this is ready for us to pick up, though temporarily blocked until on the release of the updated MenuItem component, which will happen next week (which means it’ll ride the train the following week).

MenuItem is now available AFAIK

Indeed, the new supportingText prop was included in the Codex release yesterday (0.4.0).

On Weird Gloop's wikis, we've actually backported Vector 2022's search into old Vector (we don't intend to switch to Vector 2022 in the near-term, but desire the new search functionality). Part of this has been implementing a change that allows us to show the names of redirects on the suggestion items.

I'm happy to adapt & submit a patch here that shows the name of the redirect in supportingText, as it seems relatively straight forward. Would you prefer using the exact text from the Redirectedfrom i18n message that already exists? (if so, should we use that message directly or create a new one?)