I've created the Figma spec sheet and Guidelines for the ChipInput with menu functionality in T366006.

As discussed with @AnneT, we aim to integrate both ChipInput variants, with and without the menu, into the existing ChipInput component. It will feature the following props:

Types of ChipInput

There will be 3 type of ChipInput based on how the chips are created:

1. Custom input (current version implemented):
chips can be created by typing and then pressing the Enter key, clicking outside the input, or tabbing out.
2. Preset options:
chips can only be created by selecting the predefined menu options. If there are no results for the text typed by the user, a non-interactive "no results" message will be displayed within the menu.
3. Custom input and preset options:
users can either select predefined options from the menu or add custom chips by typing and then pressing the Enter key, clicking outside the input, or tabbing out.

Selected items within the menu

When preset options are available within a menu, the selected menu items will become chips. There are 2 ways of showing these selected menu items in the menu:

1. Selected menu items disappear from the menu once converted to chips.
2. Selected menu items remain displayed in the menu as chips.

I recommend not displaying selected items in the menu when they are created as chips (1) to improve user experience, since it will be easier for the user to detect which remaining menu items they can include as chips. Please review both options in this Figma prototype.

Optional stat icon

To maintain consistency with other form items (TextInput, TextArea, Select, etc.), the ChipInput will include an optional start icon. The start icon will be visible only when no chips are included within the input, to prevent overcrowding. However, the start icon will always be visible in the version where chips are included outside the input. Please review both options in [[ To maintain consistency with other form items, the ChipInput will include an optional start icon. The start icon will be visible only when no chips are included within the input, to prevent overcrowding. However, the start icon will always be visible in the version where chips are included outside the input. Please review both options in this [[ https://www.figma.com/proto/V8MBvInCI3mXB5LNMhRzJF/Chip-Input---T337095?page-id=2101%3A62033&node-id=2101-63118&t=EymEpuWtNNrJSDId-0&scaling=min-zoom&starting-point-node-id=2101%3A63118 | Figma prototype ]].

@Milimetric with the design specs complete, this is now ready for dev. Wondering if you're still open to contributing this (which we'd be happy to support) or if we should find a time to put this into one of our future sprints to work on ourselves.

We already have a pretty good working demo at https://doc.wikimedia.org/codex/latest/components/demos/menu.html#with-multiselect that should make this task easier to implement. That demo seems to address the "menu but also allowing arbitrary user-submitted options" use case, except the arbitrary user-submitted options don't then show up in the menu (which they should).

Change #1072620 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] ChipLookup: Add new WIP component

https://gerrit.wikimedia.org/r/1072620

In T345291#10114845, @CCiufo-WMF wrote:

We already have a pretty good working demo at https://doc.wikimedia.org/codex/latest/components/demos/menu.html#with-multiselect that should make this task easier to implement. That demo seems to address the "menu but also allowing arbitrary user-submitted options" use case, except the arbitrary user-submitted options don't then show up in the menu (which they should).

For posterity, I thought I'd document here why that demo was a lot easier to build than the functionality we need to support the use cases in this task.

In the multiselect menu demo linked above, there are 2 factors that made it easy to build:

• The menu items never change
• The menu items and chips only have a single value, rather than a value plus a human-readable label

We need to support dynamic/fetched menu items, and menu items that have a label that's shown to the user plus a unique value. These things make it a lot harder to build, especially when considering allowing for arbitrary chip content. Because of these factors, the DST decided not to pursue allowing arbitrary chip content for now, to limit the complexity of this component.

@bmartinezcalvo here's a work-in-progress demo of the ChipInput with Menu, which I've built into a new component called ChipLookup. We can workshop the name, or we may decide to put the new functionality into the existing Lookup component and refer to it as a multiselect variant of Lookup.

Initial feedback would be welcome, especially around user interaction details (for example, when you delete a chip, the menu closes because the input has lost focus. Should that happen?)

El T345291#10142587, @AnneT escribió:

@bmartinezcalvo here's a work-in-progress demo of the ChipInput with Menu, which I've built into a new component called ChipLookup. We can workshop the name, or we may decide to put the new functionality into the existing Lookup component and refer to it as a multiselect variant of Lookup.

@AnneT thank you for preparing this. Regarding the component's name, we initially decided to include this as a variant of the ChipInput during the design process. However, I understand that technical requirements might need creating it as a separate component. If including it as a variant of ChipInput is not possible, I would rename it to "ChipInputMenu" for simplicity.

Here are some reasons for this preference:

• "ChipInputMenu" is more consistent with "ChipInput", making it easier for users to understand that both components are for the same purpose: adding chips within an input field. So their use will be clearer when both components are listed one above the other in the left menu.
• We don't need to specify in the name that a Lookup component is used to build it. Users only need to know the function of the component, not which other components are used.
• Both ChipInput and ChipInput with menu use a TextInput to type, so I think "ChipInput" and "ChipInputMenu" is enough to understand the purpose of both components.

Ideally, I would still prefer this to be a variant of the ChipInput to avoid confusion. But if this is not possible, I'm okay with adding it as a separate component.

El T345291#10142587, @AnneT escribió:

Initial feedback would be welcome, especially around user interaction details (for example, when you delete a chip, the menu closes because the input has lost focus. Should that happen?)

@AnneT the expected behavior is that the menu keeps open when the user removes any of the chips, similar to the MenuTagWithMultiselect in OOUI, and similar to the ChipLookup with initial suggestion, where the menu keeps open even when the user removes any of the chips. The difference between the version without initial suggestions and the one with initial suggestions, is the following:

• With no initial suggestions: the menu collapses when the last chip is removed from the input and only reopens when the user types something that matches the results.
• With initial suggestions: the menu appears as soon as the user places the cursor in the input and stays open even after the last chip is removed.

Apart from this, here are some other things I've detected:

1. A start icon could be optionally included within the input (of both ChipInput and ChipLookup) since there is an option to include a start icon in the rest of from items (TextInput, Select, Combobox, Lookup...). So let's include it in the Configurable demo if possible. Refer to the Figma spec.
2. Similar to Lookup component, if there are no results for the text typed in the input, a "no results" message should be displayed within the menu. This "no results"message is being displayed in the demo with fetched results but not in the rest of them.
   

In T345291#10143604, @bmartinezcalvo wrote:

El T345291#10142587, @AnneT escribió:

@bmartinezcalvo here's a work-in-progress demo of the ChipInput with Menu, which I've built into a new component called ChipLookup. We can workshop the name, or we may decide to put the new functionality into the existing Lookup component and refer to it as a multiselect variant of Lookup.

@AnneT thank you for preparing this. Regarding the component's name, we initially decided to include this as a variant of the ChipInput during the design process. However, I understand that technical requirements might need creating it as a separate component. If including it as a variant of ChipInput is not possible, I would rename it to "ChipInputMenu" for simplicity.

Here are some reasons for this preference:

• "ChipInputMenu" is more consistent with "ChipInput", making it easier for users to understand that both components are for the same purpose: adding chips within an input field. So their use will be clearer when both components are listed one above the other in the left menu.
• We don't need to specify in the name that a Lookup component is used to build it. Users only need to know the function of the component, not which other components are used.
• Both ChipInput and ChipInput with menu use a TextInput to type, so I think "ChipInput" and "ChipInputMenu" is enough to understand the purpose of both components.

Ideally, I would still prefer this to be a variant of the ChipInput to avoid confusion. But if this is not possible, I'm okay with adding it as a separate component.

Anne had made the argument in our sprint review that this is actually more of a "Lookup with Multiselect" rather than "ChipInput with Menu", which I agree with. In all the use cases described in this task, the intended behavior is more similar to a Lookup rather than a ChipInput or TextInput. It just so happens that you can select more than one item you look up. I'm not totally sold yet on "ChipLookup", but it does do a good job of representing both ideas: if you were expecting it to be a ChipInput variant, you'd find it pretty easily because it has "Chip" in the name. Same thing for if you were expecting it to be a variant of Lookup.

Even thinking through the documentation, the way we would describe the component is more similar to a Lookup, and all the demos would essentially be the same as Lookup.

Ok, in case we represent them as "ChipInput" and "ChipLookup", we could rephrase these component's descriptions to be clearer on how users create chips on each them. I propose the following rephrasing:

• ChipInput: A ChipInput allows users to type text which is turned into chips for filtering content or making selections.
• ChipLookup: A ChipLookup allows users to select options from a predefined menu based on their input, turning them into chips for filtering content or making selections.

Apart form this, I will work on ChipLookup Guidelines to make sure we define the differences between both components.

In T345291#10143738, @bmartinezcalvo wrote:

@AnneT the expected behavior is that the menu keeps open when the user removes any of the chips, similar to the MenuTagWithMultiselect in OOUI, and similar to the ChipLookup with initial suggestion, where the menu keeps open even when the user removes any of the chips. The difference between the version without initial suggestions and the one with initial suggestions, is the following:

• With no initial suggestions: the menu collapses when the last chip is removed from the input and only reopens when the user types something that matches the results.
• With initial suggestions: the menu appears as soon as the user places the cursor in the input and stays open even after the last chip is removed.

I've partially implemented this - basically, when a chip is removed, it has no effect on whether the menu is open or closed. The state of the menu is purely based on whether there are menu items (or "no results" content) to show. This clears up the bug where deleting a chip closes the menu, and should make the menu behavior consistent across the demos/use cases.

Apart from this, here are some other things I've detected:

1. A start icon could be optionally included within the input (of both ChipInput and ChipLookup) since there is an option to include a start icon in the rest of from items (TextInput, Select, Combobox, Lookup...). So let's include it in the Configurable demo if possible. Refer to the Figma spec.

Let's open a new task for this - since ChipInput does not contain a TextInput component, we don't get the start icon for free. We'll have to implement it in ChipInput.

2. Similar to Lookup component, if there are no results for the text typed in the input, a "no results" message should be displayed within the menu. This "no results"message is being displayed in the demo with fetched results but not in the rest of them.
   

I've added a "no results" message to all demos except the configurable one—I wanted that one to have only the default features of the component initially. that said, we can consider adding a slot control for the "no results" message if we want to - let's discuss as part of T375700 as we finalize the component so we can take it out of WIP!