Filament Rating Laravel Package

Product Decisions This Supports

• Build vs. buy for the "ratings" feature. A single composer require delivers the three surfaces a rating feature actually needs in an admin panel — the editable form field, the sortable/display table column, and the read-only infolist entry. That removes the most common reason teams write a bespoke field (you otherwise build and maintain three slightly divergent implementations).
• Scoping review/feedback modules on the roadmap. Star ratings on products, courses, content, support interactions, or internal QA scores are now a configuration decision rather than an engineering project. Half stars (halfStars()), clearable(), and showValue() cover the common product asks without custom code, so roadmap estimates for "add customer ratings" shrink to wiring + policy work.
• Accessibility commitments and procurement gates. The field is a keyboard-operable role="slider" (arrows, Home/End, Delete) with aria-valuetext ("3 of 5 stars"), and read-only columns/entries are role="img" with equivalent labels. That is the part teams routinely under-scope and then fail an audit on. If WCAG 2.2 AA conformance is a contractual or public-sector requirement, this removes a named risk item from the launch checklist rather than deferring it.
• Dependency consolidation and lock-in posture. Declared API compatibility with mokhosh/filament-rating (stars(), allowZero(), color(), size(), theme(RatingTheme::…)) means adoption is reversible: switching in is a near no-op, and switching back out is bounded. That materially lowers the cost of saying yes, and it means we are not betting a roadmap item on a single unmaintained dependency.
• Data quality for downstream analytics. Built-in validation (numeric, in-range, on-step) means rating values that reach reporting are constrained at the boundary — no 3.7 stored in an integer column, no out-of-range values from a crafted request. Ratings that feed averages, NPS-style rollups, or ranking logic are only as trustworthy as their input contract.
• Localization roadmap. Ten shipped locales (en, uk, pl, de, fr, es, it, nl, pt_BR, tr) plus RTL mirroring and panel-driven dark mode means ratings do not become a blocker for the next market launch, and we don't open a translation ticket on day one.
• Operational risk / maintenance cost. Namespaced stylesheet (.fi-rating*) and no JavaScript build step means no asset-pipeline work, no bundler coupling, and low probability of colliding with other panel plugins. For a PM this is a "low ongoing tax" signal — the kind of dependency that doesn't come back as recurring maintenance work each Filament upgrade.

When to Consider This Package

Adopt when most of the following hold:

• The product runs on Filament 5. This is the hard gate — the package targets Filament 5, so teams on Filament 3 or 4 should not plan around it.
• Ratings are needed inside the admin/panel experience (resource forms, tables, infolist detail views) rather than on the public-facing site.
• The UX requirement is a star scale (including half stars) — the 1–5 star metaphor is the product decision, not an open question.
• Accessibility is a requirement, not a nice-to-have: keyboard operation and screen-reader labelling are being asked for by a customer, auditor, or internal standard.
• You want a single fixed cost rather than a field plus a column plus an entry plus the a11y remediation work.
• Multi-locale delivery is on the near roadmap.
• You are already using or evaluating mokhosh/filament-rating and want the a11y and half-star capabilities without an API rewrite.

Look elsewhere when:

• You are not on Filament 5 — waiting is cheaper than backporting.
• The scale is not stars: thumbs up/down, emoji reactions, 0–10 NPS, or sentiment pickers are different interaction models and should be a separate evaluation.
• You need aggregate rating analytics — average score columns, rating distributions, trend-over-time — that is reporting work, not an input widget.
• You need the public-facing rating control on a Blade/Livewire page outside the panel; this package's surface is panel-scoped.
• You need review text, moderation queues, verified-purchase rules, or spam handling — that is a reviews product, and this is only the numeric input for it.
• Ratings are business-critical and long-lived and you require a formal maintenance/licence review first: confirm licence terms, supported PHP/Laravel range, and release cadence before committing — the notes describe v1.0.0, which is early for a load-bearing dependency, so treat the API-compatibility promise as the safety net and keep a thin internal wrapper around it.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible decision that unblocks a customer-facing capability we would otherwise have to build in-house. One dependency gives us the editable rating control, the read-only display, and the table column — three things we'd normally specify, build, test, and maintain separately. It ships with accessibility built in (keyboard operable, properly labelled for screen readers), which is the expensive part of this kind of component and a common cause of audit failures and launch delays. It supports ten languages out of the box, so it doesn't become a blocker for market expansion. Two risk factors are worth naming plainly: it targets Filament 5 only, and it is at v1.0.0 — mitigated by API compatibility with the established mokhosh/filament-rating package, which means we can switch in either direction cheaply. My recommendation is to adopt it behind a thin internal wrapper so the rest of our code doesn't depend on its API directly.

To engineering: Low-integration-cost, low-maintenance dependency. One package covers form field, table column, and infolist entry; no JavaScript build step and a namespaced stylesheet (.fi-rating*), so no asset-pipeline work and minimal collision risk with other panel plugins. Validation (numeric, range, step) is enforced, which keeps bad values out of downstream reporting. Accessibility is handled at the component level — role="slider" with arrow/Home/End/Delete key support and aria-valuetext on the input, role="img" with matching labels on read-only surfaces — so nobody needs to retrofit that. Constraints: Filament 5 only. Diligence items before merge: confirm licence, supported PHP/Laravel versions, and release cadence; and wrap the field/column/entry in our own thin factory methods so a future swap stays a one-file change. Given it's v1.0.0, budget a short spike to verify behaviour under our panel's theme and RTL configuration rather than assuming parity.