The latest updates on your projects. Learn more about Vercel for Git ↗︎

@Yeison07 just confirming I see this is ready for review. I've been away the last week so I'm just getting back on my feet here. It may take me a bit longer to get a proper review in, but I will asap.

@Yeison07 so reviewing this, I actually like your alternative idea, as we've had had a pending request for custom filtering for a while now:

• Allow passing a custom filter function to the Combobox component #3328

We must preserve the default behavior for backwards compatibility (to avoid a breaking change), so here's my suggestion:

1. Remove the disableAutoFilter prop in favor of a filter prop (named that if possible)
2. Set the type to take a function of course
3. Then when this is present, it should take over responsibility for the filtering feature
4. See my comment below regarding the use of $effect
5. We'll need to provide guidance on the doc page on how users can utilize this

Per the $effect I feel like there may be a better way to handle this. I'm going to defer to @Hugos68 to see if he has any suggestions. Hugo let me know your thoughts here. The goal is to ensure options state remains reactive if the original data changes externally.

@Yeison07 just checking on the status of this and the requested changes.

hi @endigo9740 , checking this out, been a bit busy and couldn't, hope to finish it tonight.

🦋 Changeset detected

Latest commit: 2ca02d3

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Hey @endigo9740 @Hugos68, I tested my code under three scenarios I think cover the main use cases for the Combobox:

1. Passing filter: null: This gives the parent full control over filtering, which I think is the best way to handle complex cases like input length checks or async API fetches. It keeps the component simple, avoids extra props, and lets the user decide how to handle the data. I went with this instead of overcomplicating the component internally, and it feels like a solid way to give users total flexibility.
2. Not passing filter (default behavior): This keeps the component's original behavior, using the default filter (item.label.toLowerCase().includes(value.toLowerCase())). It's great for static lists or simple drop-in use cases where you don't need extra logic. No surprises here, just works as expected.
3. Passing a custom filter function: This was the trickiest case. It works well for switching filters (like contains to startsWith), but I ran into an issue: when the component first gets focus, onOpenChange loads the full data without applying preconditions (like input length checks). This happens because it resets internalOptions to data. After you clear and type again, the filter works fine, but that first focus feels inconsistent. I'm not sure if this is the expected behavior or if we should tweak onOpenChange to apply the filter with the current input value on open.

Overall, I think the filter prop with null support and internalOptions makes the component flexible, especially for dynamic cases like async fetches or custom preconditions. Since this is my first time working with Zag, I might've missed some edge cases. Let me know what you think about my approach in the latest commit and if the onOpenChange behavior is okay or needs a fix. Thanks for the feedback! 👍

@Yeison07 so first things first, this looks much better.

Reviewing the original Zag implementation - which we strive to stick as close to as possible - I see filtering only occurs in onInputValueChange(), per their docs:

onInputValueChange({ inputValue }) {
      const filtered = comboboxData.filter((item) =>
        item.label.toLowerCase().includes(inputValue.toLowerCase()),
      )
      const newOptions = filtered.length > 0 ? filtered : comboboxData
      options = newOptions
},

But I would expect we could perhaps remove the need for internalOptions if we use $state.snapshot. Which could result in something like this:

let {
    // ...
    filter = (item: T, value: string) => item.label.toLowerCase().includes(value.toLowerCase()),
    // ...
}: ComboboxProps<T> = $props();

let options = $derived(data);

onInputValueChange({ inputValue }) {
    const filtered = $state.snapshot(options).filter((item) => filter(item, inputValue));
    options = filtered.length > 0 ? filtered : options;
},

This would:

• Keep the default filter as the default filter prop value as you have it.
• Keep a single derived instance of options for reactivity
• Take a snapshot of the options just before the filter is applied (like cloning)

To be honest I haven't used snapshot() heavily, so I may be making a false assumption here. And I'm not sure if there's implications to to checking the filter state, or it being explicitly null, for other parts of the logic such as onOpenChange.

I'll also again ask @Hugos68 to chime in if he has any input on your code or my suggestion here.

One final thing @Yeison07 - when we do settle on the custom filter solution. We'll need to document this alongside the Combobox itself. Likely as a small paragraph + code snippet that explains that you can replace the filtering option, and showcasing a simple use case. Let me know if you need help with this.

Also make sure to update the changset to represent the shift to the customizable filter