Inline Chart Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel visualization. An inline chart — a sparkline beside a KPI, a trend column inside a resource table — is a narrow, presentational need: no persistence, no schema, no product differentiation. This package is a credible buy: one Filament column API, sensible defaults, data fed from a model attribute, array, or closure. The in-house alternative (hand-rolling a Chart.js column inside Filament's column API) is measured in days, which caps the downside of adopting and keeps the exit cheap. Recommendation: buy, and keep the scope deliberately narrow so the exit stays cheap.
• Whether to invest in analytics at all — and how much. This is the cheapest possible experiment to learn whether operators actually consume in-context trends before you fund a BI tool, a charting service, or a warehouse initiative. If in-row sparklines get used, that's a signal to invest further; if they don't, you've spent days instead of a quarter and learned the same thing.
• Filament 5 migration sequencing. Release 3.0.0 is a compatibility release, not a feature release — the entire changelog is "support filament 5," shipped as a major bump. The decision is therefore not "do we adopt this package," it's "does inline charting survive the panel migration, or do we rebuild or drop it?" This release says survive. Fold it into the migration epic as a work item, not a standalone initiative.
• Roadmap gating on the plugin graph, not this package. The real scheduling constraint is every other Filament plugin in the admin also declaring Filament 5 support. One holdout turns per-package bumps into a blocked programme. Sequence and staff at the programme level; the long pole is almost certainly not this 23-star package.
• Risk register: ecosystem concentration. Single maintainer, 23 stars, 0 dependents, MIT license, last release 2026-03-10. That's a standing entry, not a blocker — with 0 dependents you are an early verifier of the Filament 5 path, not a follower. Mitigations are cheap: pin the major, keep the use case presentational, retain fork/vendor as fallback.
• UX investment in the admin surface. "Metric and its direction in the same view" is a genuine operator-efficiency win that costs no backend work and no infrastructure. It can be justified on operator efficiency alone, without a business case for reporting infrastructure.
• Performance budget for admin screens. Because charts render per row and per page, adoption carries a design constraint: prefer aggregate or sparkline visuals, keep series short (7–30 points), and prefer precomputed series (a JSON column or cached nightly aggregate) over per-row aggregation closures. That closure path quietly turns one table render into N queries — a decision the PM should make explicitly, not discover in production.

When to Consider This Package

Adopt when:

• You are on, or actively migrating to, Filament 5, and want compact in-context charts in table columns, resource columns, or widgets.
• The need is presentational and lightweight — trend next to a value, sparkline, simple series — not an exploration or analytics surface.
• You want a composable plugin over bespoke code, and can accept a small third-party dependency confined to the admin layer.
• You can pin the major version (^3.0 on Filament 5; ^2.0.4 on Filament 3/4) and treat the Filament major as the upgrade trigger.
• You can absorb manual verification per release — a one-line changelog means diff review and visual QA, not trust.
• You have a performance plan for charts inside paginated tables: short series, precomputed data, no per-row aggregation closures on wide tables.

Look elsewhere, or build, when:

• You need rich analytics — drill-down, cross-filtering, axes, tooltips with data tables, export tooling. Reach for a real charting library or a BI tool the first time you need to ask a question of the chart rather than look at it.
• You are not on Filament, or are staying on Filament 3/4 for the foreseeable future — this release doesn't help you; evaluate 2.x on its own merits or take no action.
• You need charting outside the admin panel — customer-facing pages, PDFs, contractual or SLA-backed reporting. Scope and support model both mismatch.
• Your policy is no single-maintainer dependencies in critical paths — this isn't one, so it may still qualify if you confine it to the admin layer and retain the wrapper seam.
• You need sorting, filtering, or CSV export to reflect the chart's value. It's a rendered visual, not a database-backed column; exports will emit raw arrays or nothing unless you handle it explicitly.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed plugin that puts a trend line directly beside a metric in our admin tables, so operators see direction and magnitude in one glance instead of exporting to a spreadsheet. It's a days-not-weeks investment with an equally small exit, and it doubles as a cheap experiment: if in-context trends get used, we have evidence to fund real analytics; if not, we've spent days rather than a quarter. It carries no infrastructure cost and no customer-facing exposure. The one caveat is concentration risk — a single maintainer — which we mitigate by pinning versions and containing it to the admin panel.

To engineering: A Filament column plugin, not a charting library. Install is one Composer line, no migrations; pin by Filament major (^3.0 for Filament 5, ^2.0.4 for 3/4 — do not install 3.x there). Treat 3.0.0 as breaking until you've read the 2.0.4...3.0.0 diff and confirmed whether it drops older Filament and still publishes its JS asset. Two non-negotiables: the column must be a projection, not a computation — feed it a precomputed JSON column or cached accessor, never a per-row aggregation closure, or a 25-row table becomes 25 extra queries; and centralise the column in a small wrapper class (TrendColumn::make()) so a future API change or a swap to hand-rolled Chart.js is a one-file fix. Colours come from the Filament palette, not hex, so dark mode and theming work for free. Decide explicitly what an empty or single-point series renders, how the column behaves in CSV exports, and whether it's toggleable on narrow screens. Test for render presence, then do a manual visual pass across light/dark, empty, short, and wide series. Finally, check whether Chart.js ships as a published asset or comes from a CDN — a CDN is a CSP and supply-chain finding that will fail in a locked-down or air-gapped admin.

The decision we're asking for: approve a scoped "buy" for admin-only inline trend visuals on Filament 5, tracked as a work item inside the panel migration epic, with the version pinned and the wrapper class in place from day one.