- How do I install amabk/livewire-search-select in a Laravel application?
- Install it with Composer using composer require amabk/livewire-search-select, then optionally publish the package config and Blade views if you need to customize markup or defaults. The package fits a standard Laravel plus Livewire stack and expects a JavaScript build step such as Vite. Most teams get a first working component in roughly half a day to two days, including wiring the search query and validation. Pin the exact version in composer.json and commit the lockfile before you start.
- Does livewire-search-select support Livewire 3?
- The package targets Livewire 3.x projects and slots in as a Blade-rendered component with an asset bundle. Livewire version support is the main integration unknown, so verify the composer constraints and any CI test matrix before adopting. If you are still on Livewire 2.x, confirm compatibility explicitly rather than assuming it works.
- How do I make the dropdown search options from a database query?
- The component performs server-side search through Livewire, so you wire it to an Eloquent query or a closure that returns matching options as the user types. Keep the query limited and indexed, and return only the fields you need for the label so each keystroke stays cheap. Per-instance work usually covers custom option formatting and validation of the selected value.
- Can livewire-search-select handle multiple selection?
- Multi-select behavior is per-instance configuration work rather than something to assume out of the box. Test the submitted payload shape carefully if you rely on wire:model binding with arrays. Review the component properties and emitted events in the v1.2.3 diff before building multi-select forms.
- Should I publish the config and views for this package?
- Publish config and views only if you need to customize option formatting or markup, and otherwise keep them package-managed so future upgrades stay simple. If you do publish, verify the asset and view paths do not collide with existing public/vendor entries. Republishing may be required after upgrades because the changelog does not document asset changes.
- Does livewire-search-select require Vite or a JavaScript build step?
- Yes, expect a client-side JavaScript asset bundle alongside the Livewire component, registered through Vite or the package's own asset directive. Whether the JS assumes a specific bundler is one of the integration unknowns to confirm on a pilot form. Run a bundle-size and Lighthouse check after adding it to a real page.
- Does livewire-search-select support keyboard navigation and screen readers?
- Accessibility is an open question because the package relies on a third-party JavaScript search library for keyboard navigation and ARIA behavior. Do a manual keyboard and screen-reader QA pass on your pilot form before rolling it out to users. Check for visible focus styles, escape-to-close behavior, and announced result counts, and document any gaps as a fallback plan.
- Is livewire-search-select a good alternative to select2 or choices.js?
- It is positioned as a lightweight alternative to bulky select libraries for teams already standardized on Livewire. You get server-side search and Livewire state sync without a large client-side dependency, though some behavior still comes from a third-party JavaScript search library. If you are migrating, run both implementations in parallel behind a feature flag and compare submitted payloads.
- Should I use a caret version constraint for amabk/livewire-search-select?
- Pin the exact version and commit your lockfile instead of using a caret constraint, at least until the release notes become descriptive. The v1.2.3 patch release says it adds functionality, fixes bugs, and updates the readme, which breaks semver expectations and means any patch could change public API surface. Read the full diff between v1.2.2 and v1.2.3 before upgrading, and watch for changed wire:model semantics or unversioned asset changes.
- Can I use livewire-search-select in an Inertia or API-only application?
- No, this is a presentation-layer component for Blade-rendered Livewire forms, so it is a non-starter for Inertia, Vue, React, or API-only front ends. It does not touch persistence, auth, or queue infrastructure, which keeps the blast radius small but also means it offers nothing for decoupled clients. It is a good fit for Blade apps, Filament-adjacent admin panels, and any Livewire-driven form.