Add metadata to Command items

[MichaelBrunn3r]

My main issue is on how to find out which item is currently selected and how to handle duplicates.
A simplified example:

<script lang="ts">
  const colors = {red: "#ff0000", green: "#00ff00", blue: "#0000ff" };
  const trafficLightStates = {red: "stop", green: "go", yellow: "slow down" };

  const value = $state("");
</script>

<Command.Root bind:{value}>
  <Command.List>
    <Command.Viewport>
      <Command.Group>
        <Command.GroupItems>
          {#each Object.entries(colors) as [name, value] }
            <Command.Item value={name}>{name}: {value}</Command.Item>
          {/each}
        </Command.GroupItems>
      </Command.Group>
      <Command.Group>
        <Command.GroupItems>
          {#each Object.entries(trafficLightStates) as [state, value] }
            <Command.Item value={name}>{name}: {value}</Command.Item>
          {/each}
        </Command.GroupItems>
      </Command.Group>
    </Command.Viewport>
  </Command.List>
</Command.Root>

If value === "red", how do I determine if the currently selected item is a color or a traffic-light state?

My current fix would be, to add more information to the value prop of each item:

...
{#each Object.entries(colors) as [name, value] }
  <Command.Item value={"color:" + name}>{name}: {value}</Command.Item>
{/each}
...
 {#each Object.entries(trafficLightStates) as [state, value] }
  <Command.Item value={"trafficLight:" + name}>{name}: {value}</Command.Item>
{/each}
...

This way, color:red and trafficLight:red can be differentiated. Luckily the search algorithm is fuzzy and we have keywords, otherwise this approach would interfere with searching. But are there drawbacks I haven't thought of yet?

I'm not sure if this is the right solution to go with or if it would be beneficial to add metadata to each item instead:

<script lang="ts">
  const value = $state("");
  const meta: unknown = $state(null);
</script>

<Command.Root bind:{value} bind:{meta}>
  ...
  {#each Object.entries(colors) as [name, colorValue] }
    <Command.Item value={name} meta={{type: "color", colorValue}}>{name}: {colorValue}</Command.Item>
  {/each}
  ...
</Command.Root>

[huntabyte]

The value should be unique to the item, otherwise there can be multiple items "selected" at the same time. Your usage of keywords is the recommended approach, or you can append something to the end of the value before it is passed into the component to ensure it is unique while not interfering with the scoring algorithm.

To determine which one is selected, you can use the onSelect callback for each item, since you know at the time of iterating what the true value is (whether it is a traffic light or a color), you can handle it like so:

{#each trafficLights as [name, value]}
<Command.Item onSelect={() => {
	mySelectedValue = trafficLights[name]
}} />
{/each}

{#each colors as [name, value]}
<Command.Item onSelect={() => {
	mySelectedValue = colors[name]
}} />
{/each}

[huntabyte]

So in my eyes, the metadata would be shifting something onto the lib that may not be ideal for all use cases, when you essentially have whatever metadata you need during iteration and can handle selection logic accordingly if that makes sense.

[MichaelBrunn3r]

Thx, I will go with the keyword/prefix/suffix approach. Adding prefixes worked for me until now, I was just unsure if I missed out on a better solution. Not adding metadata makes sense.

(Just to make sure, I was talking about "selecting" in the sense of vim navigation or hovering over an item, not "selecting" in the sense of clicking or pressing "Enter" on an item. The second isn't really an issues, as you said, because onSelect exists.)

[huntabyte]

Would knowing when something is/is not highlighted be a useful callback to expose if feasible? Something similar to what we do for the combobox/select:

Reference: https://bits-ui.com/docs/components/combobox#comboboxitem

[MichaelBrunn3r]

Absolutely. Callbacks require more work on the user side, e.g. when a reactive state of the currently selected item is required. But that's straight forward, so I don't see this as a downside. Plus, it offers more flexibility than a bindable meta prop