Filament Infinite Select Laravel Package

Technical Evaluation

Architecture fit. The package occupies a deliberately narrow seam in the stack. It is a Filament v4 form field that subclasses native Select, plus one published Alpine component and a service provider that registers the asset. It holds no opinion about the data layer: all domain logic stays in the host app behind a single getPaginatedOptionsUsing($offset, $limit, $search) closure that returns an options value-to-label map and a hasMore boolean. For a panel already on Filament, this is close to the minimum possible integration surface — the package owns the interaction pattern, your closure owns authorization scoping, search semantics, and query cost. That division is what makes this a TPM-shaped decision rather than an architecture debate: there is no new service to operate, no schema change, no search infrastructure, no queue.

Integration feasibility. Per field the work is roughly one make(), one closure, and one label resolver. The label resolver is not optional: loaded pages need not contain a previously saved value, so without getOptionLabelUsing() / getOptionLabelsUsing() edit forms render raw IDs — a visible data-quality defect rather than a cosmetic gap. Configuration is four fluent calls (perPage() default 15, preloadFirstPage(), searchDebounce() default 300ms, scrollThreshold() default 50px). A Filament-fluent developer is productive in under a day. The one pipeline dependency is asset publishing: php artisan filament:assets must run on every deploy that can change the package version, and a 404 on that path produces a select that renders and silently never loads.

Technical risk. The dominant risks live in the closure pattern we author, not in the package itself. Offset pagination drifts: rows inserted or deleted mid-session produce duplicated or skipped options and possibly a stale label against a saved record — acceptable for admin tooling, disqualifying for audit-sensitive surfaces. The first documented example computes hasMore with a separate count(), doubling round-trips per page; the limit + 1 pattern exists and should be mandated internally rather than left to author discretion. An unindexed LIKE '%term%' search converts a payload win into a query-cost regression. Separately, adoption signal is thin — 10 stars, 0 dependents, one maintainer, a low composite score — so there is no community-vetted edge-case library and effective bus factor is one. There is also no stated support matrix beyond "Filament v4," meaning a Filament minor bump is an untested combination until staging proves otherwise.

Key questions. Does the closure fire once per scroll request, and what is the Livewire round-trip cost per page? How does the field behave inside modals, repeaters, and nested relation managers, where selector scope and asset loading differ? Do exists and required validation rules still fire against the submitted ID? Can we enforce a server-side page cap and minimum search length to bound request amplification? Is Filament v3 support on the roadmap, and what is the maintainer's cadence against Filament majors? What exactly crosses the wire per page — options only, or additional Livewire state that compounds? Finally: what is the maximum option count per lookup field in our own panel, and which fields actually exceed the usable ceiling for a native searchable select?

Integration Approach

Stack fit. PHP 8.x, Laravel 10–12, Filament v4 panel. Alpine ships with Filament, so there is no JS toolchain on the host side; the entire footprint is one Composer dependency plus one asset-publish command. Eloquent, query builder, or a service class all work behind the closure provided the return contract is honored. The field subclasses native Select, so it composes with existing form definitions rather than replacing them.

Migration path. Treat Select::make()->searchable() as the baseline and InfiniteSelect as a per-field substitution, never a rewrite. Because the builder surface is compatible, rollback is a one-line change per field — that reversibility is the strongest argument for a pilot over a blanket standard. Start with a single high-cardinality field (tenant, user, customer, or taxonomy picker with thousands of rows), ship behind a feature flag, and keep the previous implementation reachable until the closure is proven under real search traffic.

Compatibility. Pin the version and check its Filament constraint against the panel's before install. Add filament:assets to every deploy step that can change package versions — not just first install. Verify the published asset path resolves in the deployed environment; panels routing /js through a CDN or a non-default public root are a common silent failure for this class of package. Confirm Livewire alignment before any Filament minor upgrade, and use the bundled playground/ as a behavioral reference only, never as a substitute for testing against our own panel.

Sequencing. (1) Spike one field in a dev panel to confirm asset publishing and scroll behavior end to end. (2) Extract the pagination closure into a reusable, unit-tested data provider per entity, so limit + 1, permission scoping, and indexed search columns are enforced in one place instead of copy-pasted across fields. (3) Add label resolvers to every field before release — release-blocking, not follow-up. (4) Pilot behind a flag with closure invocation counts and query timings instrumented server-side. (5) Review measurements against the pre-pilot baseline, then extend to remaining high-cardinality selects. (6) Publish an internal snippet codifying the house closure pattern so new fields do not diverge from it.

Operational Impact

Maintenance. MIT-licensed and small enough to enumerate: one PHP field class, one Alpine component, one service provider. That is forkable and self-maintainable if the maintainer goes quiet, and saying so explicitly in the adoption record converts a bus-factor-one risk into a bounded contingency. Budget a recurring task at each Filament upgrade to re-verify the field and re-run asset publishing, and read upstream changelogs on every bump — with this few dependents, nobody else surfaces regressions for us.

Support. No vendor SLA; the burden lands on the platform team. The ticket queue is small and each item has one known cause: "dropdown shows IDs" (missing label resolver), "spinner never stops" (closure throwing or returning hasMore: true indefinitely), "options stopped loading after deploy" (unpublished asset or 404 on the JS path), "saved value disappeared" (offset drift or a genuinely deleted record). A one-page runbook covers nearly the entire surface, and the first line of triage is almost always the closure or the asset step rather than the package code.

Scaling. The trade is one large payload for N small ones. At 15 rows per page, a form that hydrated thousands of options becomes a handful of indexed queries per user — a clear win when each page is cheap, a regression when the closure does an unindexed LIKE plus a count(). A user paging a large table with search plausibly generates 5–15 requests per session. Instrument closure invocations server-side, because the client layer exposes few telemetry hooks, and enforce a minimum search length and a page cap before enabling the field on any entity. Index the searched column first; that single step determines whether adoption is a performance gain or loss.

Failure modes. (a) Asset 404 — the select renders, never loads, and shows no visible error; this needs a deploy smoke check, not user reports. (b) Closure exception — the spinner hangs with no user-facing message; wrap and log. (c) Offset drift — options duplicate or vanish between pages, and a selected label may not match the stored ID. (d) Saved value outside loaded pages with no resolver — a raw ID in the edit form, which is the most likely first bug in production and the cheapest to prevent. (e) Runaway hasMore — a closure that always reports more results produces endless scrolling and request amplification. Two pilot signals catch most of this: closure latency and invocation volume per form.

Ramp-up. Low, and that is the point. A Filament-fluent developer learns the field in hours; the learning curve is in the house closure pattern, not the package. Front-load that pattern into a documented internal data-provider base class plus the runbook, and subsequent fields become a copy of a reviewed template. The recommendation this assessment supports is a time-boxed pilot on one high-volume field, measured on form load time and task completion, with native searchable select kept one line away as the fallback — pilot, not org-wide standard.