Filament Timeline View Laravel Package

Product Decisions This Supports

• Build vs. buy on feed UI. A day-grouped, responsive, dark-mode-aware activity feed with avatars, kebab actions, and native Filament filter/search integration is realistically 3–5 engineering days plus design review. Here it's a composer require and one column swap. The decision is close to a no-brainer for a view-layer surface.
• Unblocking a backlog of "feed-shaped" requests. Any ticket sitting in the queue because "we don't have a feed UI" becomes addressable: company announcements, employee/department pulse, audit and change history, ticket or order activity logs, shipment tracking history, patient or account timelines, changelog pages.
• Roadmap sequencing. Because the package consumes an existing table query (->query(), ->groups(), ->filters(), ->searchable(), ->recordActions(), ->paginated()), it can ship as a presentation variant on a resource you already have rather than a new feature track. It can ride along with an existing resource release instead of owning a sprint.
• Dashboard / exec-visibility features. The TableWidget support is the commercially interesting bit: a "Company Pulse" or "Account Activity" panel on a dashboard becomes a widget definition, not a new page type.
• Scoping a build-vs-replace question with a real artifact. Rather than debating whether users want a chronological view or a grid, ship the timeline behind a toggle on one low-risk resource and read engagement. Cheap, reversible experiment.
• Prioritization signal on presentation debt. If three or more resources end up timeline-shaped, you've learned something about how your users actually read this data — that's roadmap evidence, not just a UI tweak.

When to Consider This Package

Adopt when:

• You are already on Filament v5 and PHP 8.2+. This is a hard gate — the constraint is filament/tables ^5.0, so v3/v4 shops are out until they upgrade.
• The data is inherently time-ordered, and the primary user question is "what happened, and when" rather than "find record X" or "compare these rows across columns."
• The surface is internal or back-office: admin panels, ops dashboards, support tooling. Blast radius of a UI regression is contained.
• The layout fits an established, recognizable pattern — a feed is a known idiom, not a novel interaction users must learn.
• You want the double-sided layout for an announcement/comms surface and the single-sided layout as the workhorse elsewhere.

Look elsewhere when:

• You need bulk actions, row selection, or dense multi-column comparison. The package documents record-level actions, filters, search and pagination — bulk selection on card layouts is not represented. Validate this before committing an ops workflow to it.
• The surface is customer-facing or revenue-critical. 23 stars, zero dependents, and one maintainer is not a vendor relationship. MIT means you can fork, but budget the willingness to maintain it.
• You expect long-lived support or an SLA, or you're planning a Filament v6 upgrade path — the package hooks Filament's macro and column-layout APIs, which are exactly the seams that move between majors.
• You need export, saved views, or column configuration — grid tables give these free; a card feed won't.
• Your volume is large and untested. "Load more" is a different interaction contract from page links; validate performance and pagination behavior against real data before rollout.
• Custom card interior is a requirement beyond the opinionated TimelineEntry setters — though note the documented escape hatch (drop in Stack/Split layout columns and the chrome still renders), which softens this considerably.

Two implementation items to plan for, not discover: Filament's date grouping sorts ascending by default, so newest-first needs an explicit orderQueryUsing; and collapsible day groups are opt-in, not default.

How to Pitch It (Stakeholders)

To executives: This is a presentation-layer package that turns an existing admin table into a chronological feed. No database migrations, no new data store, no new query surface, no vendor contract — MIT licensed, one composer dependency, scoped to a view. Estimated saving is roughly a week of design and engineering per surface, and the exit cost is close to zero: removing it means restoring ->columns(). The honest risk is maintenance concentration (single maintainer, low adoption), which is why we'd pilot it on one internal, non-revenue surface first and treat broader adoption as a second decision.

To engineering: Zero plugin registration — the service provider auto-loads and registers its table macros; one php artisan filament:assets after install. Critically, it doesn't invent a new abstraction: you compose with standard Filament query / groups / filters / searchable / recordActions / recordUrl / paginated APIs, swap ->columns() for TimelineEntry::make(), and call ->asTimeline() or ->asDoubleSidedTimeline(). Filters, deferred filters, session persistence, filter layouts, and search all pass through to Filament's own implementation. When the opinionated card doesn't fit, you can replace TimelineEntry with stock Stack/Split layout columns and keep the dot, caret, card chrome, and action kebab. Two known config items: set orderQueryUsing for newest-first date groups, and call ->collapsible() on the Group if you want day collapse. What we need to validate before wider rollout: bulk-action behavior, pagination at production volume, and whether the ^5.0 pin will hold through our next Filament upgrade.