Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Livewire Async Select Laravel Package

drpshtiwan/livewire-async-select

A lightweight async select component for Laravel Livewire and Alpine.js, offering a modern Select2 alternative with dynamic option loading, debounced search, multi-select chips, Tailwind styling, custom slots, and full wire:model binding.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy for the "searchable dropdown" problem. Every Laravel admin surface eventually needs an entity picker — assign a user, tag a record, pick a category from thousands of rows. The default path is a hand-rolled Alpine combobox (a week of engineering plus a permanent maintenance tail) or dropping in Select2 (jQuery in a modern stack). This package is a third option: ~4 lines of install and one Blade tag. That reframes the decision from "which engineer owns this component" to "do we accept a dependency."

  • Unblocking async-heavy forms without a frontend build. The component loads options from any application endpoint returning {"data": [...]}, with debounced search handled client-side. This means a PM can greenlight features like "assign this ticket to any of 40,000 customers" or "add collaborators by email" without scoping a Vue/React island or a JS bundler change. The work becomes a backend endpoint plus a template edit — a form a Laravel team can absorb inside a normal sprint.

  • Closing the perceived-quality gap on core CRUD screens. Multiple selection with chip/tag display, custom option rendering via slots, and a suffix button that can open a "create new" modal (added in 1.1.0) are the small affordances that make an internal tool feel finished. These are usually the first items cut when a design system isn't ready, and this package supplies them pre-built with a las- class prefix that avoids collisions with an existing Tailwind config.

  • Roadmap sequencing for design-system and theming work. With Bootstrap 4 support added in 3.2.0 and Tailwind as the default, the package is theme-agnostic. A PM can defer a broader design-system investment and still ship consistent form controls, or adopt it as the interim standard while a system is built.

  • Security posture decisions for internal APIs. The async-auth middleware mirrors Laravel's auth but adds signed, replay-protected internal tokens and supports web, sanctum, and api guards. This lets a PM approve exposing search endpoints for authenticated pickers without commissioning bespoke token plumbing — though it also raises a question worth asking early: does introducing a second auth path alongside Sanctum complicate our security review?

  • Reducing jQuery-era technical debt. If any part of the product still leans on Select2 or similar, this is a credible, scoped migration target rather than an open-ended frontend modernization project.

When to Consider This Package

Consider it when most of the following are true:

  • The stack is already Laravel 11–13, PHP 8.2+, Livewire 3.3+/4.x, and Tailwind is present or the Bootstrap 4 theme covers your styling needs.
  • You have several entity-picker fields (roughly three or more), so the install cost amortizes. For a single field, an inline Alpine component is honestly cheaper than a dependency.
  • Your option sets are large enough or volatile enough that eager-loading all choices into the page is a real performance or staleness problem.
  • You need multi-select with tags, custom option rendering, or a create-new affordance — the features that make hand-rolling expensive.
  • You are comfortable owning a thin JSON search endpoint per picker, and can accept the layout-level requirements (@asyncSelectStyles, @stack('scripts'), published CSS assets).
  • You want a contained blast radius: it's a single form input, not a framework, with no persistence model, queue, or service-container override to unwind.

Look elsewhere when:

  • You are not on Livewire. This is strictly a Livewire child component; there is no value outside that stack.
  • Adoption risk outweighs the savings. 112 stars and zero dependent packages is thin social proof. The hygiene is genuinely above average — tests, CI, Pint, a changelog, and semantic versioning through 3.3.0 — but "field-tested at scale by other teams" is not a claim that can be made. For a customer-facing, high-traffic, or compliance-sensitive surface, a first-party component or a more established library is defensible.
  • Your design system is mature and opinionated. If you already have a vetted combobox, a second one creates a fork in the UI standard regardless of class prefixes.
  • You cannot tolerate a solo-maintainer dependency and have no appetite for forking under MIT if the project goes quiet.
  • The picker needs capabilities beyond scope — rich relational filtering, server-side pagination with infinite scroll, or complex grouped hierarchies would need verification against the docs first.
  • Your security review will not accept a parallel auth mechanism into internal endpoints, in which case budget time for a design conversation, not just an install.

How to Pitch It (Stakeholders)

One line: A small, MIT-licensed UI component that gives our Livewire forms modern async search-and-select behavior — the thing Select2 does — without jQuery, without a frontend build, and without a design-system dependency.

To executives: This is a low-cost lever on perceived product quality and a small one on engineering throughput. It replaces repeated hand-built dropdowns with a supported component, which means fewer bespoke implementations to maintain and faster delivery of features that involve picking users, tags, or records. Cost is one dependency and roughly a day of integration; upside is reclaiming engineering days across the next several forms we ship. The honest caveat is adoption risk: it's a young package with a single maintainer and no downstream dependents. It's MIT, so the worst case is we fork or vendor it — the exit cost is low and bounded, which is why the risk is acceptable for internal and admin surfaces, but not for a flagship customer-facing flow without a pilot.

To engineering: Four commands and three Blade directives. It binds through wire:model natively, delegates interactivity to Alpine, and expects you to own the search endpoint — a five-line closure or thin controller returning {"data": [...]}. It ships an async-auth middleware that behaves like auth and supports web/sanctum/api guards, so you don't have to invent token handling. Custom rendering is available via Livewire named slots on 3.3+/4.x with callable slots as fallback. We'd want your read on two things before committing: whether a second auth path beside Sanctum is acceptable to the security review, and whether we pin the version and wrap it in our own Blade partial so a swap later is a one-file change.

Recommended next step: pilot on one internal admin screen with a single high-cardinality picker, time the integration honestly, and decide on a broader standard after we've lived with it for a sprint.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
gmostafa/php-graphql-client
xeviant/paystack
snowsoft/faker
meditationsteps/blogetc
animalyoung/laravel-influxdb
onix-solutions/sms-telera
lonely-lights/prosetta
oxygen/data
oxygen/core
jengo/base
xiloryx/log-collector
a21ns1g4ts/filament-stripe
la-php/laravel-admin
artisan-build/community-prompts
vleroy/smart
ayles-software/laravel-australian-public-holidays
cboxdk/laravel-id-spatie
cboxdk/laravel-id-billing
cboxdk/laravel-id-billing-bridge
simple-as-fuck/php-performance-log