Livewire Search Select Laravel Package

Getting Started

Install the package with Composer and confirm the service provider is auto-discovered:

composer require amabk/livewire-search-select

Start with the README — v1.2.3 explicitly refreshes it, so it is the most current source for prop names and component signatures. Check for a publishable config or asset tag (php artisan vendor:publish --tag=...) if you need to override default styling or search behaviour.

Your first use case should be the one the package exists for: replacing a <select> with hundreds of options with a searchable, Livewire-bound dropdown. In a form component, bind the component to a public property via wire:model (or the package's documented model binding), pass the option list in, and verify two things end-to-end before building further: that selecting an item updates the Livewire property, and that validation errors render against the component as they would on a native select.

Implementation Patterns

• Form binding first. Treat the search-select as a drop-in for <select> inside an existing Livewire form component. Keep validation rules on the parent component ('selectedId' => 'required|exists:...') rather than duplicating them in the view.
• Server-side search for large sets. For anything beyond a few hundred records, prefer passing a searchable query/callback over preloading a full collection into the component. Keep the search term debounced and let Livewire round-trip it.
• Create-inline flows. Common pattern: allow an "add new" affordance when no results match, dispatch an event to the parent component, persist the record, then re-hydrate the option list and set the new value.
• Dependent selects. Chain two search-selects (e.g. country → city) by listening for the parent's updated hook, clearing the child value, and reloading its options. Guard against the child firing updated on clear and re-triggering the parent.
• Composition with Alpine/JS. Use the package for the search UX and keep state in Livewire; avoid maintaining a parallel JS array of selected values, which drifts on re-render.
• Testing. Assert on the underlying Livewire property rather than rendered markup where possible — component internals may shift between patch releases.

Gotchas and Tips

• Vague changelog. v1.2.3 ships "adds functionality" and "fixes bugs" with no itemised list. Before upgrading, diff v1.2.2...v1.2.3 on GitHub or skim the merged PRs; do not assume the patch is behaviour-neutral in the search/filter path.
• Re-render loss. If options are rebuilt mid-request, an already-selected value can be dropped when it is not present in the new option list. Always include the currently selected record in the options payload.
• Wire model modifiers. .live on the search input is usually what you want; .defer on the selected value reduces requests but delays validation feedback — pick deliberately.
• Keying and wire:key. When looping several search-selects, give each a stable wire:key tied to the field name, otherwise Livewire may reuse DOM and show the wrong dropdown's state.
• Styling conflicts. Tailwind purge and CSS specificity on the dropdown container are frequent culprits when results appear unstyled or hidden behind modals — check z-index and overflow on ancestors before blaming the package.
• Debugging search. Log the query and the returned option set in the component rather than the rendered HTML; most "no results" reports trace to an empty search term or an over-restrictive where clause.
• Extension points. Prefer overriding the published view or config over editing vendor files so the next patch release does not silently revert your changes.
• Pin the version in composer.json until you have read the diff, then run your form tests on upgrade.