feat: separate value from text content when filtering

[Kinbaum]

I have a use case where I want my value to be different than the label presented to the end user. When typing in the search field today, the user would have to know the underlying value to be able to see something return.... typing what is visible text content wouldn't yield the expected filtered results.

My ask is that we change the behavior so that the search field only looks at the text content rendered (we have to pass this anyway for something to show up). The only way an average user would know what the value is is if they opened their dev tools, which is not expected.

[raunofreiberg]

You should be able to pass a value prop to Command.Item and use children to display the label.

[Kinbaum]

Yes I understand this, but as I’ve pointed out, doing so affects the filtering capability. It will only filter on the value, not the children’s text content

[pacocoursey]

I think this is a valid use case that is a little difficult in the current API.

@Kinbaum Can you share where you want to use this internal-only value? Inside of onSelect?

---

As a workaround, you could include both values in the value string:

<Command.Item value={`${internal}:${searchLabel}`}>{searchLabel}</Command.Item>

[Kinbaum]

I think so. And I’ve been stringifying a JSON object as sort of a hack for the filtering aspect (still has issues - see below)

A use case would be pushing the user to a new route on select of an item.

But this also poses challenges when setting the current value as that cannot be derived from the cleaned URL if you go with the hacked approach.

[Kinbaum]

@pacocoursey Is there any update on this feature request

[akd-io]

~I have unique IDs for each of the items in my list, but because filtering happens on values and not labels, I'm having to use the labels as values, which is not ideal.~

~I wonder why filtering was done on values, to begin with. Isn't it always preferred to filter on labels?~

Edit: I realise the differentiation of labels and values I'm talking about is one added by shadcn/ui, which I'm using on top of cmdk. Not surprisingly, adding a label/value abstraction on top of a library that doesn't support the label isn't going to yield great results. I'd highly recommend supporting both labels and values, where filtering happens on labels.

[akd-io]

I think I was very confused in my last comment on here. I really wanted value to be a unique identifier, but I don't know why.

My requirements have changed a bit since. I now need to be able to find items with additional hidden search terms. I was able to get things working perfectly by appending additional search terms to the value property and using a custom filter function.