Add search to Builder block picker

[KianAcquoy]

Description

Adds an opt-in search field to the Builder block picker, to quickly filter large block lists. It reuses the CanBeSearchable concern from CheckboxList, so searchPrompt(), noSearchResultsMessage() and searchDebounce() are also supported. The field is auto-focused when the picker opens, using a new reactive isOpen property on the shared dropdown Alpine component.

Builder::make('content')
    ->searchable()
    ->blocks([
        // ...
    ])

Visual changes

Without searchable

With searchable

Functional changes

• Code style has been fixed by running the composer cs command.
• Changes have been tested to not break existing functionality.
• Documentation is up-to-date.

[danharrin]

Thanks for this! A few things need addressing before we merge:

• Please keep the search labels in sync when the available blocks change, for example when a block reaches maxItems(). Alpine currently retains the original labels array after a Livewire morph, so searches can hide the wrong blocks.
• Escape currently closes the picker as well as clearing the search. The dropdown handles Escape before the input’s stopPropagation(). Please make the first Escape clear a nonempty search, then close on the next Escape and return focus to the trigger.
• Please search HTML labels as they appear to the user. Stripping tags leaves entities encoded, so a label displaying R&D doesn’t match a search for R&D.
• Please add tests for the new configuration and browser behavior, including changing available blocks, keyboard interaction, and accessibility checks in light and dark modes.
• Please define the supported search configuration directly on Builder rather than using CanBeSearchable. That concern also exposes methods such as searchValues() and searchLabels() which have no effect here.

[KianAcquoy]

Thank for the feedback, Dan. I've addressed all points in my latest commit.

While moving off CanBeSearchable I noticed CheckboxList has the same issue: it uses the concern but never reads searchingMessage(), noOptionsMessage(), searchLabels() or searchValues(). Maybe we should resolve that in a follow-up PR?

[danharrin]

Yeah a follow up PR would be good thanks