Command palette - not fuzzy search?

[danielrona]

Command palette is not a fuzzy search

new

creaty new

I expected this to be a fuzzy search, clearly it is not, bug or a feature?

[joshhanley]

@danielrona thanks for reporting! At this stage it's not a bug as such, but we do agree that it probably should be supported. I have converted this to a feature request instead.

[christopherarter]

Just piggy-backing off of this too. Ideally if we could pass in a closure as well that would be 👌

Thanks for your work on Flux!

[hannesw]

+1. This also applies to other components like searchable selects or autocomplete.
Maybe an elegant solution could be a simple prop like

<flux:autocomplete fuzzy>

[schonhoff]

This would be awesome. Maybe something like Flexsearch is used for fuzzy search. Or use a closure on the filter function to add your own filtering algorithm. Had Minisearch first but this will also work only for start of words and not in the middle of the word. I switched back to FlexSearch after this was questioned by a client.

[calebporzio]

Yeah, I think something like "fuzzy" would be nice. Does anybody have opinions on how "fuzzy" should behave?

[danielrona]

Similar to this would be nice

[vincentcordel]

I agree too.
Not having this function makes the autocomplete and command pretty useless IMHO :(

[beneyraheem]

I think relying on startsWith() can be too restrictive for most use cases.

While it ensures an exact match at the beginning of the string, it doesn't account for scenarios where users may expect a match anywhere in the string. For example, searching for "app" in "pineapple" won't return a match, which might feel unintuitive to users.

Switching to includes() offers a more flexible search experience, as it allows matches to occur anywhere within the text. This would improve usability and make the search feel more responsive without introducing the complexity of fuzzy search.

If fuzzy search is too much to implement for now, includes() is a solid middle ground that balances flexibility and simplicity.

    matches(el, search) {
        return el.textContent.toLowerCase().trim().startsWith(search.toLowerCase().trim())
    }

to

    matches(el, search) {
        return el.textContent.toLowerCase().trim().includes(search.toLowerCase().trim())
    }

[joshhanley]

As a work around for now, you can currently implement fuzzy search on the backend but turning off frontend filtering by passing :filter="false" to command.

public $search;

#[Computed]
public function commands()
{
    $commands = collect([
        'Assign to…',
        'Create new file',
        'Create new project',
        'Documentation',
        'Changelog',
        'Settings',
    ]);

    return $commands->filter(function ($command) {
        return str_contains(strtolower($command), strtolower($this->search));
    });
}

<flux:command :filter="false">
    <flux:command.input wire:model.live="search" placeholder="Search..." />

    <flux:command.items>
        @foreach ($this->commands as $command)
            <flux:command.item wire:click="..." icon="user-plus">{{ $command }}</flux:command.item>
        @endforeach
    </flux:command.items>
</flux:command>

[joshhanley]

@beneyraheem not sure what you mean about the searchable search manually, but the select component also supports the :filter="false" attribute.

Regarding the startsWith(), that's just how it was written initially as it's simpler I believe.

I think Caleb is open to adding this (see #126 (reply in thread)).

But there are questions around how it should be implemented:

• Like is fuzzy search find the search value anywhere in the text?
• Do we want to search the beginning of each word?
• Do we want to be able to still search only from the beginning like the current implementation?

All of these (and possibly more) are validate options, so it would be good to get a consensus on what is best.

[vincentcordel]

personally, what i’m used to see is “type any set of characters” (uppercase or lowercase) and show the corresponding results no matter where it is.

ex.
search “app” returns:

• Application
• rapper
• this is an apple

[beneyraheem]

personally, what i’m used to see is “type any set of characters” (uppercase or lowercase) and show the corresponding results no matter where it is.

ex. search “app” returns:

• Application
• rapper
• this is an apple

Exactly, now the search is very difficult, when it is startsWith()

[schonhoff]

Maybe it is possible to implement both solutions. The startsWith approach can be enough for some folks and is very good for the performance. The fuzzy, contains or includes implementation comes with a performance drop in large cases. That way Flux can deliver the needs for both worlds.

Another way to approach the topic would be to create an opportunity for the user to implement its own search. That way the user can implement a Search JS library like FlexSearch, MiniSearch or others (i love the list from FlexSearch https://github.com/nextapps-de/flexsearch?tab=readme-ov-file#compare-web-bundles). I think this would be the most flexible way but also the most difficult way supportwise.

Edit: The solution from Josh is very good but it isn't on the client side. That way there are a lot of network requests.

[mcalonje]

I agree with vincentcordel and beneyraheem about a fuzzy search being the expected behavior for an autocomplete., and I do think it would be good to be able to search from the beginning if one wants to as well, as schonfoff mentioned. However I would also like to be able to specify case-sensitivity for the search as an option. For example, on my page I have a list of plant names such as Zamia wallisii and Ceratozamia robusta. If I typed the word 'Zamia' I would like it to only filter 'Zamia wallisii' from the list.

[calebporzio]

Ok, I'm going with @beneyraheem's suggestion for now. Using .includes() instead of .startsWith(). This will be in the next release.

We can keep the discussion going about more fuzzy options, but I think this is a better default and solves most people's needs (for example, this is select2's default behavior).

Thanks for bringing this to my attention and suggesting such a simple solution. I might have overcomplicated this otherwise.

[calebporzio]

Just checked and the <datalist> element in HTML (the native autocomplete element when combined with an input) uses .includes as a strategy instead of .startsWith. So I think it's safe to say this is a better default.

[calebporzio]

Btw, here is my dream algo as the default:

• use .includes to narrow the results initially
• then "score" that subset.
• highest score for exact match, second for "startsWith", third for "wordStatesWith", fourth for just a substring

However, because we are just filtering DOM elements in-place and not rendering them based on a dataset, anything that changes the order of the search results will have to be done in developerland using Alpine or Livewire. Super bummer, but whatever, .includes is good enough.

[jeffchown]

Love the thought and attention to detail, @calebporzio.

Thanks re changing to .includes - despite not being the dream ;), it's still a solid improvement over .startsWith