Nova Detached Filters Laravel Package

Product Decisions This Supports

• Admin UX / internal-tooling roadmap. This package exists to remove a specific, measurable friction: operators reopening the Nova filter dropdown dozens of times a day on the same resource. Detaching the two or three highest-frequency filters (order status, ticket state, date range) into an always-visible toolbar is a concrete efficiency win for ops, support, and finance workflows. Frame it as operational productivity work, not customer-facing product strategy.
• Build vs. buy on a narrow presentation customization. Detached rendering is a small, well-understood surface: a Laravel/Nova team could replicate it in roughly a day for a single resource. The package forces that trade-off into the open — adopt a thin MIT dependency now, or own and maintain an in-house component later. For one resource, build. For several resources where you want consistent behavior this sprint, buy — and budget for the Nova-upgrade validation that comes with it.
• Backlog prioritization inside the admin panel. A low-effort, high-visibility item that answers a recurring internal complaint ("I have to open the filter menu every time"). It belongs in a polish or efficiency sprint, not a strategic roadmap commitment. It does not justify its own initiative.
• Standardizing admin filter patterns. Adopting this is implicitly a UX governance decision: which filters detach, which stay in the dropdown, and how many can sit in a toolbar before the table gets pushed below the fold. Decide the convention once ("status and date range detach, everything else stays"), document it, and apply it uniformly — inconsistent placement across resources generates more support questions than the dropdown ever did.
• Plugin portfolio and vendor-risk review. With 63 stars, 0 dependents, and a single-maintainer lineage (Outl1ne / optimistdigital) whose releases largely track Nova majors — 3.0.1 is explicitly a Nova 5 type-compatibility fix — this is a useful case study for a broader question: how many small Nova plugins are we carrying, who owns upgrade risk for each, and does every one have a named fallback (fork, in-house replacement, or removal)?

When to Consider This Package

Adopt when:

• You are already running Laravel Nova. The package is meaningless outside Nova, and Nova itself is a paid, licensed product — so this is purely an additive admin-UX decision, not a platform decision.
• You have several resources with genuinely frequent filters — orders, users, tickets, audit logs — where operators demonstrably reopen the dropdown repeatedly within a session.
• You want the improvement this sprint and are comfortable with a thin MIT-licensed package from a known Nova plugin maintainer.
• Your Nova major version is explicitly supported by the pinned release (verify against src/ and the release notes, not a blog post) and your Nova upgrade cadence is controlled and centrally gated.
• You can scope adoption to a pilot on two or three high-traffic resources with a measurable success criterion — reduced filter-related support tickets, or observed click reduction — before standardizing.

Look elsewhere or build in-house when:

• You are not on Nova, or still evaluating Nova itself. Filter placement is a downstream detail, not a reason to choose the platform.
• You require enterprise support, SLAs, or a formal security review trail. With 0 dependents and a small star count, community validation is essentially absent; you are trusting one maintainer's track record.
• You perform frequent Nova major upgrades. Small Nova plugins are a common source of upgrade breakage, and a stale compatibility matrix can block a platform upgrade you actually care about.
• You need capabilities beyond presentation — saved filter presets, cross-resource filters, or persistent/shareable filter state. Detached filters remain query-string based and reset on fresh navigation unless the underlying filter defines a default(). This package delivers visibility, not persistence; if stakeholders asked for "filters that stay applied," it does not solve their problem.
• Your team has strong opinions about admin UI consistency and would rather own the component. MIT permits forking, but forking means you maintain it — treat the fork as the extension point, since the package has no meaningful config surface.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk usability tweak to our internal admin panel, not a customer-facing product change. It makes the filters our ops, support, and finance teams use most often permanently visible on the screens they live in, instead of hidden behind a dropdown they reopen all day. Integration is an afternoon per resource with no migrations, no config, and no asset build step; the package is MIT-licensed and already in use on the Nova 5 stack. The real cost isn't installation — it's a small recurring tax at each Nova major upgrade, which we contain by pinning an exact version, gating Nova upgrades on a manual check of affected resources, and piloting on two or three high-traffic resources before rolling it out. Ask: approve a timeboxed pilot on our busiest resources, with a success measure of fewer filter-related support tickets.

To engineering: A thin, Nova-native package that wraps an existing filter class in DetachedFilter::make(...) inside filters(), so the filter renders outside the sidebar dropdown. It is presentation only — apply() and canSee() behave exactly as they do in the dropdown, and mixed arrays (some detached, some in the dropdown) are the intended shape. Constraints to plan around: a filter must appear exactly once in filters() (wrapping and returning the raw instance double-applies its constraint); state stays in the query string, so use default() if a selection should stick; custom Vue filter components that assume they live inside Nova's dropdown container will look broken when detached, so validate against the most complex one during the spike; and stale precompiled assets after deploy is the classic false alarm — clear Nova's caches before debugging PHP. Cap detached filters at three or four per resource and verify the reset affordance clears both detached and dropdown filters together. Budget an hour of smoke-test coverage (assertOk() on each affected resource) to catch Nova-upgrade mount failures in CI.

To the sponsoring ops/admin team: Set expectations precisely — this changes where filters live, not how long they remember. Selections still reset when you navigate away unless a filter is given a default, so "always show me open orders" is a configuration choice we make per filter, not a feature of the package. Mobile and narrow laptop viewports degrade first; we'll check the toolbar around 1280px and 1024px and detach fewer filters on smaller screens rather than shipping a wall of controls that pushes the table off-screen.