Nova Filters Summary Laravel Package

Product Decisions This Supports

• Feature prioritization for internal tooling. This card supports a specific, defensible decision: funding a small admin UX fix when the evidence points to hidden filter state as the source of confusion. If support tickets, mistaken exports, or repeated "is this all the data?" questions cluster around filtered Nova indexes, this is a cheap, contained remedy. It is a clarity and trust fix, not a new capability — size it and defend it that way.
• Build vs. buy vs. vendor. The package is roughly one PHP Card class plus one Vue component, built JS included. That makes "adopt the package" and "copy ~200 lines into nova-components/" nearly the same decision on cost. The PM framing is: pick the path that gets the pilot running fastest, and treat vendoring as the likely steady state rather than a fallback. The real spend is the compatibility spike, not the integration.
• Roadmap placement. Belongs on an admin/back-office or operations roadmap — analyst efficiency, dashboard trust, support deflection. It does not advance customer-facing product goals and should not compete for platform budget. Sequence it behind any Nova version migration, because a Nova major bump changes the Vue runtime underneath the card.
• Where to scope the pilot. Target high-signal surfaces first: resource indexes where users stack three or more filters (orders with status + date range + customer relation is the canonical case), and lens-based segmented views where switching lenses silently rewrites filter state. A one-filter index is the wrong pilot — the card adds vertical space and no information.
• Scope discipline as a decision. The card displays state; it does not persist, govern, or audit it. Saved filter presets, filter history, governance-grade reporting, and cross-tool dashboard transparency are separate product decisions with separate business cases. Deciding to adopt this card is not a down payment on any of them, and bundling them will stall the adoption call.
• Success criteria you must instrument before launch. Filter-related support ticket volume on the pilot screens, filter-reset frequency per session, time-to-insight on filtered views, and mistaken exports. If none of these are measurable today, the pilot cannot produce a decision — instrument first, then ship.

When to Consider This Package

Adopt when all of these hold:

• Laravel Nova is in production and there is no plan to leave it in the next 12–18 months. Without Nova this package has zero applicability.
• Users on the in-scope screens genuinely stack filters or switch lenses. You can name the screen and the filter combination.
• You can quantify the confusion cost today — tickets, rework, bad exports, repeated verification questions. If you cannot name the cost, you cannot justify the pilot or evaluate it.
• A compatibility spike passes on a representative resource and a lens: Nova major verified against the Vue runtime (Nova 4 = Vue 3, Nova 3 = Vue 2), assets publish cleanly, and date/range, multi-select, boolean, and any custom filter types in use all render as readable values rather than raw arrays.
• The card re-renders on Nova's partial-page filter change rather than going stale. Nova applies filters without a full reload, so a server-computed summary can disagree with the table. A summary that contradicts the data is worse than no summary.
• You accept the dependency profile: 20 stars, zero dependents, single maintainer, last release January 2025. Pin the version, run Composer audit, and budget the effort to own the code.

Look elsewhere or build in-house when:

• The requirement is saved presets, audit history, or governance-grade reporting — this package displays state, it does not persist it.
• The need spans multiple tools, not just Nova. One card does not solve a cross-tool transparency problem.
• Anyone requires vendor support or an SLA. There is none.
• The card proves stale on filter change and the team has no appetite to patch the Vue component.
• Filter uriKey()s are unstable or filters get renamed often — renaming a filter class silently changes the key any summary depends on, which is a breaking change in disguise.

How to Pitch It (Stakeholders)

For executives. A small, low-risk enhancement to our existing Nova admin screens that makes the currently active filters visible as a compact summary above every table. The business problem is trust: when a dashboard is filtered, operators cannot easily see what is being excluded, which produces support tickets, mistaken exports, and wasted time re-checking whether the data is complete. Effort is measured in days, there are no database changes and no migration, and removal is clean. The decision gate is a measurable reduction in filter-related support load across two or three high-traffic screens. If the pilot does not move that number, we drop it.

For engineering. A Nova card — one PHP Card class and one Vue component — registered either globally in NovaServiceProvider::cards() or scoped per resource/lens via a cards() method. Scoped registration is the recommended default; global registration puts the card on every index and dashboard where "active filters" is often meaningless. There is no domain logic and no persistence; it presents what already exists in the filter query parameter. The integration is a Composer require and a registration line. The actual work is validation: (1) Nova major and Vue runtime compatibility plus asset publishing; (2) whether the summary refreshes on Nova's partial-page filter change or requires a client-side patch; (3) correct rendering and escaping across date/range, multi-select, boolean, and custom filter shapes. The summary's quality is a direct function of our filter naming — name() values and labeled options are the copy users will read, so "Status: 2" instead of "Status: Active" is our bug, not the package's.

Recommendation. Run a timeboxed spike in staging on one filter-heavy resource and one lens, confirming freshness after a filter change and correct rendering of every filter type in use. Then pilot on the support/ops dashboards that generate the tickets, with the success metric instrumented before launch. At the end of the pilot, make one of three explicit calls: standardize on the package, vendor the card into nova-components/ and own the customizations we already know we want (clear-all, chip colours, collapse-after-three), or walk away. Note that the reset affordance matters: the card is read-only by design, so pairing it with a one-click clear-all is part of a coherent pilot, not scope creep — but saved presets and history are a separate decision and should stay out of this one.