alexwenzel/ajax-select
A Laravel package for AJAX-powered select inputs that let users search and load options from a remote endpoint as they type, handy for large datasets like users or products where preloading every option isn't practical.
Architecture fit. This is a Laravel Nova field package — a PHP Field subclass paired with a compiled Vue component that Nova loads from public/vendor. That constrains it hard: it only delivers value inside a Nova admin panel on a Laravel app. It is not a reusable Blade/Livewire/Inertia component, so it does not help any customer-facing or non-Nova surface. Where we do have Nova (internal tooling, back-office CRUD), the capability it targets — an async-searchable select plus a cascading child select — is a genuine gap. Nova's first-party BelongsTo::searchable()->dependsOn() covers parent→child reactivity but does not give a clean filtered, paginated option search for large relation tables, so the problem statement is real. The opportunity: 47.54 versus score: 0.01 split is the whole story: real need, essentially zero validation.
Integration feasibility. Mechanically straightforward — composer require, register the field in a Nova resource, point it at a search callback. Practically it is a two-part verification exercise: (1) confirm Nova major-version support, since Nova 5 moved to Vue 3 and changed the field/meta contract, and the 2025-03-25 release suggests but does not prove v5 readiness; and (2) confirm how the AJAX options are served. That second point is the gating question. A field that ships its own route or reuses Nova's field endpoint has very different security characteristics, and the package's thin documentation means this must be read from source, not docs. Developing or testing this requires a paid Nova license in every dev and CI environment, which adds friction to any contribution or test harness we build.
Technical risk. High, and mostly not about code quality. Two stars, zero dependents, and no visible downstream production usage means there is no crowd-sourced regression coverage: nobody else is finding the breakages for us. Single-maintainer packages installed inside an admin panel are also a privileged supply-chain surface — the package runs with full application and DB context. Licence is MIT, which is the one clearly favourable signal: it makes forking the default option rather than a fallback. Treat the dependency as code we adopt, not a dependency we consume.
Key questions to answer before committing.
authorizedToViewAny?LIKE on unindexed columns?laravel-nova npm package is not public)?Stack fit. Assumes Laravel 10/11, PHP 8.1+, and Nova 4 or 5. Scope it explicitly to back-office Nova resources; do not let it leak into a general form strategy, because nothing about it transfers off Nova.
Migration path. Default recommendation: do not composer require from Packagist. Vendor a fork into packages/nova-ajax-select (or app/Nova/Fields) at a pinned commit, retain the MIT attribution, and treat it as first-party code. Cost is low — a field package is a few hundred lines of PHP plus a small Vue component — and it converts an unowned runtime dependency into something we can patch, test, and upgrade on our own schedule. Only consume upstream directly if the spike shows active maintenance and a responsive maintainer, which the adoption numbers do not currently support.
Compatibility. Build a version matrix before writing product code: Nova 4 vs 5, PHP 8.1–8.4, and the exact Laravel major. Confirm the compiled asset is present and loadable, since we cannot rebuild it without Nova's private npm package. If the JS must be rebuilt, budget for a rewrite of the Vue component against current Nova conventions — at that point, in-house is the cheaper path.
Sequencing.
Maintenance. Effectively ownerless upstream. Assume we own it from day one and assign a named maintainer. Realistic budget: 1–2 engineer-days for initial fork hardening (tests, endpoint review, CI) and roughly one day per Nova major upgrade for compatibility work. That is acceptable for one admin field and unacceptable if it becomes the pattern for a dozen fields.
Support. No commercial support, no meaningful issue-triage history to infer maintainer responsiveness, and two stars means the "ask the community" escape hatch does not exist. Our internal runbook — how the endpoint is scoped, how to rebuild or patch the field — is not optional documentation, it is the support model.
Scaling. Every keystroke is an HTTP request against the options endpoint, so the load profile is user-count × typing speed against a LIKE query. Enforce a minimum query length (2–3 chars), debounce client-side, cap result sets, and ensure the searched columns are indexed. If option tables grow past low six figures, expect to add a dedicated search index or a cached option payload rather than tune the query. This is the most likely place the integration degrades under real usage.
Failure modes to design against.
Ramp-up. For engineers: moderate. Writing a Nova custom field requires familiarity with Nova's field API and its non-public JS tooling, so keep ownership to one or two people rather than spreading it. For end users: near zero — it renders as a familiar dependent select, which is precisely why it is worth having. Net assessment: a small, contained, genuinely useful capability wrapped in a package we should adopt as code and operate as our own, not depend on.
How can I help you explore Laravel packages today?