Livewire Combobox Laravel Package

Technical Evaluation

What it is. A Blade/Livewire component that renders a cascade of dependent <select> inputs. Changing a parent triggers a server round-trip that repopulates child options from Eloquent, with recursive rendering to support arbitrary nesting depth and configurable model/column mappings. It is a presentation-layer component only — it owns no schema, no migrations, no persistence.

Architecture fit. Fits a Laravel monolith already committed to Livewire for form/filter UI. Not applicable to Inertia/Vue/React front ends or API-only backends — every interaction is a Livewire round-trip. Best-fit use cases are admin/back-office filters, address pickers, and category/taxonomy trees where the depth is genuinely unbounded. Poor fit for anonymous, high-traffic public forms where a round-trip per select change is unacceptable.

Integration feasibility. Low-to-moderate. The codebase is small enough to audit fully, and MIT licensing permits forking and vendoring. The real obstacle is vintage: last release 2021-05-12 puts it squarely in the Livewire 2 era. Livewire 3 changed wire:model to deferred-by-default, renamed lifecycle hooks, replaced $emit with dispatch, and requires a single root element in views — all of which this package's Blade templates are likely to violate. Verify composer.json constraints before estimating; if it pins livewire/livewire:^2.0, adoption forces a framework-wide version freeze.

Technical risk. High relative to value:

• Archived upstream. No bug fixes, no security patches, no CVE response. Every defect becomes yours.
• Low signal. 26 stars, single maintainer, no evidence of CI or a test suite. Treat the code as a sample, not a library.
• Dependency cascade. A Livewire 2 pin propagates into Laravel version constraints, which propagates into PHP version constraints and every other package in the graph.
• Unaudited authorization surface. Option queries are driven by user input; if the component doesn't scope queries per-tenant/per-user, a dropdown becomes a record enumeration endpoint.

Key questions.

1. Which Livewire and Laravel majors are in production today, and is an upgrade to Livewire 3/4 already planned?
2. Does the product actually need infinite depth, or would 2–3 fixed levels with explicit relationships suffice?
3. What is the expected option-list size per level, and what query volume per interaction is acceptable?
4. Is there an existing authorization/policy layer the option queries must route through?
5. Who owns the fork if we vendor it, and what is the maintenance budget?

Verdict. Do not adopt as a production dependency. Score 0.13 alongside an archived repo and a 2021 timestamp means this is a reference implementation, not a package. Its value is as a worked example of recursive dependent-select rendering.

Integration Approach

Stack fit. Laravel + Livewire + Blade only. If the application is on Livewire 3 or later, plan on rewriting the component regardless of what composer require reports — the Blade markup and event wiring will not survive as-is.

Migration path — three options, in preference order:

1. Fork and vendor (recommended). Copy the component class and views into app/Livewire/ and resources/views/livewire/ under the MIT license. Modernize for the target Livewire version: convert to wire:model.live, swap $emit for $this->dispatch(), collapse views to a single root element. Small enough to complete in days, and it eliminates the archived dependency entirely.
2. Reimplement natively. A dependent-select cascade in Livewire 3 is roughly 100–200 lines: a component holding an array of selected values, a recursive Blade partial, and a updated() hook that clears descendants and reloads the next level. Use the package's recursion approach as the design reference.
3. Adopt as-is. Only defensible on Livewire 2 and only for an internal, low-risk screen with a documented exception. Even then, pin the version and accept the freeze.

Compatibility checks before committing to any path.

• composer.json constraints on livewire/livewire, illuminate/*, and PHP.
• Presence of $listeners, $emit, or Livewire::listen — all signals of Livewire 2 idioms.
• Multiple root elements in the Blade views (breaks Livewire 3).
• Whether wire:model uses deferred or live binding; the cascade is non-functional if deferred.
• Any ->get() on unbounded option queries — an N+1 and payload-size problem regardless of version.

Sequencing.

1. Spike (1–2 days). Build a 3-level cascade on a branch against the current stack, using the package source as a starting point. Confirm the rendering pattern works and measure query count per interaction.
2. Decide. Adopt / fork / reimplement, recorded as an ADR with the version-freeze tradeoff stated explicitly.
3. Harden. If forking: add feature tests covering cascade reset, validation, and authorization scoping; add a query-count assertion so future changes can't reintroduce N+1.
4. Pilot. Wire into one non-critical form. Instrument with Telescope or a query listener.
5. Roll out form by form. There is no cross-cutting infrastructure here, so blast radius stays deliberately small.

Operational Impact

Maintenance. Effectively zero upstream. Every bug, framework-compatibility break, and security issue is yours to fix. The fork needs a named owner and a line in the maintenance budget; an unowned fork is worse than the original dependency because it looks maintained. Archived status also means no security advisory channel — you must proactively assess the option-query code against your own authorization model.

Support. No vendor, no SLA, no release notes beyond a README. Expect to read source to answer edge-case questions. Community support is negligible at 26 stars, so plan on internal documentation of the config surface and the recursion contract.

Scaling. The dominant cost is round-trips: each select change is a full Livewire request, and a user traversing five levels generates five requests, each potentially issuing a query per level. Mitigations:

• Cache::remember option lists keyed by (parent_id, level), invalidated on write to the underlying table.
• Composite indexes on the foreign-key columns used for filtering.
• Load only the next level on demand rather than pre-rendering the whole tree.
• Watch payload size — the component serializes every option into the DOM; a 5,000-row level will degrade render time and Livewire's snapshot size before it degrades the database.

Failure modes.

• Stale descendants. Parent change doesn't clear child selections, producing a valid-looking but inconsistent submission. Must be enforced server-side.
• Validation bypass. Dropdown constraints are client-side; a crafted request can submit out-of-tree combinations unless server rules re-derive them.
• Authorization leakage. Option queries that don't route through policies let users enumerate records they cannot otherwise see.
• Out-of-order responses. Fast interaction can render a child list from a superseded parent value.
• Upgrade fragility. Livewire major upgrades will silently break the component's binding and event wiring — no upstream fix will arrive.
• Recursion blowups. Deep or cyclic hierarchies (a category parented to its own descendant) can loop or exhaust memory without a depth guard.

Ramp-up. The API surface is small; a competent Laravel developer is productive in under a day. The hidden cost is the tribal knowledge around the fork — version pins, the recursion contract, and the caching invalidation rules. Budget half a day of documentation at fork time to avoid re-deriving it every time the component is touched.