Filament Infinite Select Laravel Package

Product Decisions This Supports

• Fix a specific broken field, not a platform. When an admin picker (customer, tenant, product, taxonomy term) holds hundreds to low thousands of options, the native Filament Select degrades: slow form hydration, truncated result sets, or a search box that only works if the user already knows the exact name. InfiniteSelect swaps that for a paged, scrollable lookup that issues roughly 15-row queries per interaction instead of rendering everything up front.
• Build vs. buy, with a credible fallback. The alternative is a bespoke Livewire/Alpine component or a broader admin-search redesign. This package collapses the work to a Composer dependency, one pagination closure, and a handful of fluent config calls (perPage, preloadFirstPage, searchDebounce, scrollThreshold). MIT license means no procurement cycle. The fallback (forking a small package, or reverting to native searchable()) should be written into the decision, not discovered later.
• Roadmap sequencing. You can ship the field fix now and defer the platform-level admin search rework. Because the component subclasses native Select, rollback is a one-line change per field. That reversibility is the strongest argument for a time-boxed pilot rather than a blanket standard.
• A data-volume inventory you are forced to produce. Adoption requires answering: what is the realistic maximum option count per lookup field, and which fields exceed the usable ceiling? The same inventory tells you where native searchable() is already sufficient, which is the cheaper answer for most fields.
• Use-case fit. Best where users browse or scan for a record they cannot name precisely. Poor fit where the job is strict type-ahead over very large datasets, which Filament's native getSearchResultsUsing already handles, typically with better keyboard and screen-reader behaviour.
• Risk decisions it surfaces rather than hides. Infinite scroll removes the total result count from the UI. Multi-select state is a plain array, so storage (JSON cast vs. pivot table) becomes an explicit product decision. Offset pagination can drift mid-session, producing duplicated or skipped options and a stale label on a saved record. Acceptable for internal admin tooling, not for audit-sensitive surfaces.
• An operational commitment it creates. The Alpine component is a published Filament asset. php artisan filament:assets must run in every deploy that can change package versions, not just on first install. A 404 on that path yields a select that renders and silently never loads, so this is a deployment-pipeline decision to make before rollout.

When to Consider This Package

Adopt only when all of these hold:

• You are on Filament v4. This is a v4-only plugin with no stated support matrix beyond that.
• A specific field has hundreds to low thousands of options and is causing measurable pain: slow form loads, truncated lists, or failed selection tasks.
• Users need to browse as well as search, not just type an exact string.
• You will supply getOptionLabelUsing / getOptionLabelsUsing on every field. Without them, edit forms render raw IDs, which is a visible data-quality bug, not an optional nicety.
• You will write the pagination closure to apply $search on every page and use the documented limit + 1 pattern rather than a separate count() query (the first documented example doubles round-trips per page).
• You can scope the closure by permission and confirm the searched column is indexed. An unindexed LIKE '%term%' turns a payload win into a query-cost regression.

Look elsewhere when:

• Options are under roughly 100. Native Select::make()->searchable() is simpler and better supported.
• The real need is type-ahead across very large datasets. Filament's native searchable select with getSearchResultsUsing already covers it.
• You need grouped options, create-option/tagging, cascading selects, or rich option rendering. Confirm support before committing; do not assume it.
• You need vendor support or a compatibility guarantee. Around 10 stars, 0 dependents, a single maintainer, and a low composite score mean no evidence of a version-support policy or broad production validation. Effective bus factor is one. Treat it as early-stage.
• Requirements include total result counts, strict keyboard/screen-reader parity, or permission logic too complex to express cheaply in one closure.
• You cannot add asset publishing to the deploy pipeline, or your /js path is served through a CDN or non-standard public root, which is a common silent failure for this class of package.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed UI component that fixes one concrete admin performance problem, unusable pickers on high-volume forms, without a platform rework. Cost is low: one dependency, one query closure per field, one asset step in deploys. The risk is dependency maturity, not technical difficulty: roughly 10 stars, zero dependents, one maintainer. Recommendation: a time-boxed pilot on a single high-volume field, measured on form load time and task completion, before any wider standardisation. Keep the fallback (native searchable select) one line away.

For engineering: Swap the field to InfiniteSelect, provide a paginated closure returning options and hasMore, and apply $search on every page using the limit + 1 pattern rather than a separate count(). Add label resolvers for single and multi-select; this is a release blocker, not follow-up work. Tune perPage, searchDebounce, and scrollThreshold. Add php artisan filament:assets to every deploy step and smoke-check that the asset path resolves in the deployed environment. Extract the closure into a reusable, unit-tested data-provider class per entity so scoping, indexing, and hasMore correctness are enforced in one place instead of copy-pasted. Pin the version, note the Filament v4 constraint, and wrap usage in a thin internal adapter so reverting is a single-file change.

Verdict: Pilot, not org-wide standard. Adopt where browse-heavy, high-cardinality fields are a genuine UX failure; skip where native searchable selects already work. Watch two signals during the pilot, closure latency and invocation volume per form, which together catch the most likely failure modes: runaway hasMore, unindexed search, and request amplification.