Filament Async Column Laravel Package

Product Decisions This Supports

• Unblocking slow-data roadmap items without a data-layer project. Any planned feature where a table cell needs a per-record remote or expensive value — shipment ETAs, credit scores, external enrichment, live pricing — today forces a trade-off between a slow table and dropping the feature. AsyncColumn decouples "the table renders" from "the value resolves," so those features can ship on the current data architecture instead of waiting on a caching/batching initiative.
• Build vs. buy on loading-state UX. v1.1.2 ships four loader presets (skeleton default, spinner, dots, bar) plus loaderColor() bound to the Filament palette. That is design-system work — CSS animation, color tokens, dark-mode variants, reduced-motion handling — that would otherwise be specced, built, and maintained in-house across every panel. Buying it removes a recurring line item from the design/frontend backlog.
• Turning loader styling into a product convention rather than a ticket. Because loader() and loaderColor() accept per-row closures, design can standardize rules like "spinner in primary for externally-fetched values, skeleton for enrichment," or vary by severity (amber tint for a late ETA). That becomes a documented convention, not a per-table code change.
• Accessibility compliance with no separate workstream. Every preset halts animation under prefers-reduced-motion, and loaderColor() resolves through registered Filament colors including dark mode. An audit finding that would normally get its own ticket is closed by adoption.
• A scheduling win: decouple the upgrade from the feature. The release is explicitly backward compatible — loadingState() still takes precedence, and columns using neither method render the same skeleton as before — so the dependency bump can ride a routine maintenance window while loader adoption is planned independently.
• Representative use cases: order tables with live fulfilment/shipment status, CRM lists backed by third-party scores, dashboards with per-row metrics from services the app does not own, and any admin panel where a row-level API call costs hundreds of milliseconds.

When to Consider This Package

Adopt when most of these hold:

• You are on Filament and building tables there — the value lives entirely inside the Filament column lifecycle; it is not a general Laravel async utility.
• At least one column's value comes from a per-record remote call or expensive computation, and you want the table to paint before those values land.
• You want the loading affordance handled declaratively — per column, optionally per row via closures — instead of owning custom loadingState() markup.
• The loader must match the panel's theme (palette colors, FilamentColor::register() entries, dark mode) and respect reduced-motion, for brand or accessibility reasons.
• You already have, or plan to add, caching/throttling around the underlying calls. The package governs presentation while a value resolves; it does not batch, queue, cache, or limit concurrency.
• You can accept a single-maintainer dependency (10 stars, zero dependents today) for a small, presentation-only surface, with a documented fallback: revert to a standard column with a synchronous or preloaded value.

Look elsewhere or defer when:

• Values resolve fast enough that the loader flashes rather than informs — the presets add nothing.
• You need table-level or bulk async behavior (batched fetching, queued enrichment with progress). That is a different architectural problem.
• You need bespoke loading visuals (illustrations, branded animations, non-CSS assets). The presets are deliberately pure CSS; loadingState() remains the escape hatch.
• You are not on Filament, or outside the package's supported Filament major — an unsupported major is a blocker, not a risk to manage.
• You need documented error/timeout behavior before committing: the materials describe only the happy path, and the re-render call multiplier (does resolveUsing() fire on every sort/filter/paginate?) is the single most important unknown to measure first.

How to Pitch It (Stakeholders)

For executives: This is a small, additive release to a package that keeps data-heavy admin tables responsive when individual values come from outside services. It gives us four ready-made loading indicators and brand-color theming out of the box, plus automatic support for users who disable motion — work we would otherwise scope and maintain ourselves. It is backward compatible: existing columns render exactly as before unless we opt in, so it can ride a routine dependency update with no migration and no downtime. The value is faster perceived performance on slow-data screens and one less piece of custom UI to own. The caveat is dependency risk, not technical risk: it is a single-maintainer, MIT-licensed package with a small surface, so we pin to a tested minor and keep a one-afternoon fallback.

For engineering: v1.1.2 adds AsyncColumn::loader() with skeleton (default), spinner, dots, and bar, plus loaderColor() accepting any Filament palette color, including FilamentColor::register() entries, following dark mode. Both accept closures evaluated per row. Implementation is pure CSS — no JS bundle — and each preset stops animating under prefers-reduced-motion. Precedence is explicit: loadingState() still wins, and columns using neither method emit the same skeleton as before, so the bump should be a no-op diff. Note that loaders change perceived performance, not actual call volume: confirm the pinned Filament major is supported, measure whether resolveUsing() fires on initial render versus every Livewire re-render (sort, filter, search, paginate, poll), and check failure/timeout behavior before broadening adoption. Then pilot loader()/loaderColor() on one genuinely slow internal table, agree a convention (skeleton default, spinner for waits past a threshold), and roll out with caching and throttling in application code ahead of wider use.