- How do I install asantibanez/livewire-select in a Laravel application?
- Install it with composer require asantibanez/livewire-select. There are no migrations, kernel-mutating service providers, or published config you must tune, so adoption is mostly just adding the dependency. You can optionally publish the package views if you need to customize the markup, then invoke the Blade component inside a Livewire view with an options method.
- Which Laravel and Livewire versions does livewire-select support?
- The package is built as a thin Blade and Livewire abstraction, so it works best with Laravel 9 through 11 alongside Livewire 3 and Alpine 3. Its public surface relies on wire:model bindings, event dispatch, and Alpine directives, and those details changed between Livewire 2 and Livewire 3 and between Alpine 2 and Alpine 3. Check the pinned release for exact version constraints before upgrading a host application's Livewire major version.
- How do I build a dependent dropdown such as country, region, and city with livewire-select?
- You compose the component with a wire:model binding and an options method on the parent Livewire component, and the child selection is driven by a parent-driven listener event. When the parent value changes, the component re-queries its options from the server, which keeps chained selects in sync without hand-written JavaScript. A quick spike on one representative form, like country to region to city, will surface nearly all integration issues in under a day.
- Does livewire-select support searchable select inputs with async server-side searching?
- Yes, server-driven searching is a core use case alongside dependent dropdowns. The component handles async option loading so you can query large option sets without embedding them all in the initial page payload. If your option lists are always small, embedding them may still be simpler and cheaper than adding round trips.
- Do I need Alpine.js or Tailwind CSS to use livewire-select?
- Yes, the component relies on Alpine.js directives and event bubbling to wire up interactions, so the host application needs a compatible Alpine version installed. The styling assumes Tailwind CSS conventions, so you will likely need to publish and adjust views if your app uses a different CSS strategy. Watch out for Alpine plugin conflicts if your app already ships its own Alpine setup.
- Can I use livewire-select for multi-select inputs or pre-populated edit forms?
- The package focuses on searchable and dependent single-select flows, so multi-select and reliable pre-population on edit screens are areas you should verify against the current release rather than assume. They may require custom work or a published view override. Test both cases early if they are part of your form requirements.
- Is asantibanez/livewire-select actively maintained and safe for production use?
- It is an MIT-licensed package with a single maintainer and roughly 515 GitHub stars, and the recorded dependent count is unusually low, so third-party validation of production traffic patterns is limited. That makes version-coupling and maintainer responsiveness the main risks rather than security, since validation of submitted IDs remains the host application's responsibility. The mitigation is cheap: the package is small enough to fork and vendor if upstream activity stalls.
- How do I test livewire-select components in CI?
- You can rely on Livewire's standard testing helpers such as assertSee and call to exercise the parent component, its options method, and the resulting state changes. Those tests cover the server-side behavior well. Keyboard interaction and Alpine-driven browser behavior are better covered with browser tests if accessibility and JS wiring are critical for your project.
- How does livewire-select compare to a native select, Select2, or Choices.js?
- If your dropdown options are static and never depend on another field, a native select element is lower risk and lower cost. JavaScript libraries like Select2 or Choices.js handle search client-side but leave you wiring dependent loading yourself. livewire-select makes sense when you are already in Livewire and want dependent, server-driven options without adding extra JavaScript.
- What are the performance and accessibility trade-offs of server-driven selects?
- Each selection change triggers a server round trip, so measure the latency cost on high-latency mobile flows before committing to the pattern for every form field. Accessibility and keyboard behavior should be reviewed against your WCAG commitments, since the package may not meet them out of the box and could need patching. Validation and error surfacing also need to be checked against Livewire's $errors bag so messages appear correctly around the component.