Nova Slider Filter Laravel Package

Technical Evaluation

Architecture fit. nova-slider-filter remains a leaf-level UI extension for Laravel Nova. It hooks into a well-defined seam: a filter class extending Nova's Filter base, registered in a resource's filters() method, paired with Vue components registered through Nova's asset pipeline. There is no service provider, no middleware, no database migration, and no impact on application domain code. Blast radius is limited to the Nova filter panel on one or more resources. v1.0.1 does not change this — it is a one-line behavioural fix inside the existing component, not an architectural change.

Integration feasibility. Unchanged and still straightforward for a team already running Nova: require the package, add the filter to the resource, supply min/max props and the target column, and confirm the apply() method issues a scoped whereBetween. Effort remains under a day including QA. v1.0.1 adds one practical constraint: pin to ^1.0.1, not 1.0.0. The v1.0.0 defect is that the default value was not set on first load, which means the slider can render in an uninitialised state and the first interaction produces bounds the admin did not intend — or, depending on how the resource configures defaults, applies a range constraint on a query that the admin believes is unfiltered. That is a correctness bug in the exact area (default/empty state) previously flagged as unverified, and it is now confirmed rather than hypothetical.

Technical risk.

• Nova version coupling (high, unchanged). Still a dependency on a closed-source commercial framework whose Vue component API and filter contract have moved across majors. Vue 2 → Vue 3 in Nova's frontend remains the most likely breakage point, manifesting as a filter that renders but silently fails to apply.
• Single-maintainer abandonment (high, marginally softened). v1.0.1 is an external contributor PR merged upstream, which is mild evidence the repo is not fully abandoned. It is one commit, roughly two years after release, with 13 stars and no dependents. Revise the framing from "unmaintained source" to "very-low-velocity source you are adopting" — the fork-from-day-one recommendation is unchanged, and the arrival of this fix does not create a support relationship.
• Default-state correctness (medium → confirmed defect, now mitigated upstream). v1.0.0's first-load default bug is exactly the class of issue the verification gap predicted. The fix does not retroactively validate boundary handling, null/empty ranges, decimals, or negative values; those still require our own assertions, and the fact that a default-state bug survived to a 1.0 release is a reason to raise rather than lower scrutiny of the remaining edge cases.
• Input-to-query surface (low–medium, unchanged). Confirm parameter binding rather than string interpolation, and confirm behaviour on inverted or open-ended ranges.
• Licensing (low, unchanged). MIT plus a paid Nova licence per project. Forking is permitted and remains the intended escape hatch.
• Package identity (new, low). The release is published under the dcasia GitHub org while the assessment has referenced digital-creative/nova-slider-filter as the Composer name. Confirm the Composer package name, repository owner, and whether a rename/transfer occurred before pinning a version in composer.json.

Key questions.

1. What Nova and PHP versions are declared in composer.json, and does it declare Vue 3 compatibility?
2. Is the Composer package name still digital-creative/nova-slider-filter given the dcasia repository owner — and which name should the fork track?
3. Does Nova now ship a native range/interval filter that makes this redundant?
4. With the default-value fix in place, what is the intended behaviour when only one bound is set, and does the filter compose correctly with lenses and metric scoping?
5. Who owns this internally if upstream goes quiet again — and is that person resourced for Nova upgrade cycles?

Integration Approach

Stack fit. Laravel + Nova shops only. The decision is still "do we want a slider affordance in this admin panel," not "do we adopt a library." The value proposition — replacing two numeric inputs with a single draggable range control — is unchanged by a patch release.

Migration path. Fork from day one, as before, and now baseline that fork on v1.0.1 so the default-value defect is not inherited. Vendor the source under an internal namespace (e.g. App\Nova\Filters\RangeSlider wrapping or extending the package class) so that a Nova major upgrade is fixed in hours, internal class names stay stable, and swapping to a native Nova filter later is a one-line change per resource. Because upstream does merge occasional external PRs, keep a lightweight patch file or annotated diff rather than a hard divergence, so the next upstream fix can be reviewed and cherry-picked.

Compatibility. Gate on a two-hour spike in a disposable Nova instance on the team's exact Nova and PHP versions: install at ^1.0.1, register on a resource with a known dataset, publish assets, and verify the generated SQL — including the first-load render before any interaction, which is precisely what v1.0.0 got wrong. Do not proceed if assets require a full npm build of the Nova toolchain in CI.

Sequencing.

1. Spike and SQL verification against the production Nova version, asserting both the untouched first-load state and a post-interaction state.
2. Decide build-vs-adopt: if only one or two resources need range filtering, a native SelectFilter with preset buckets may deliver most of the UX benefit at zero dependency cost.
3. If adopted, internalise the fork at v1.0.1, add a smoke test asserting the emitted whereBetween bounds and that no constraint is applied before first interaction.
4. Roll out to a single low-traffic resource, then generalise.
5. Record it in the internal Nova component inventory with an explicit "reassess at next Nova major" note and the upstream version pinned.

Operational Impact

Maintenance. Low steady-state code churn, high latent risk, unchanged. Budget roughly half a day per quarter plus a spike at each Nova major to re-verify rendering and query behaviour. The fork is tracked manually against upstream; v1.0.1 is a reminder that upstream is not zero-velocity, so check the changelog at each review rather than assuming silence.

Support. No vendor support and no meaningful community. Internal ownership remains mandatory. A merged community PR is not a support channel, and the two-year gap to the first fix means we should not plan around upstream responsiveness.

Scaling. Negligible. The filter resolves to a bounded whereBetween on the filtered column; performance is a function of indexing on that column. The only scaling-adjacent concern is asset recompilation if the package ships unbundled JS compiled per deployment.

Failure modes.

• Silent default range (now fixed upstream, still worth a regression test): on first load the slider could apply a default range the admin did not choose, hiding records while the panel looked inert. This is the v1.0.0 defect and the reason to pin ^1.0.1 and assert first-load behaviour.
• Silent no-op: filter renders but apply() returns an unmodified query after a Nova upgrade. Still the most dangerous case; mitigate with an assertion test on emitted SQL.
• Render failure: Vue component throws on mount, producing a blank or collapsed filter panel; visible and quickly caught.
• Null/inverted range: unguarded bounds producing a full-table scan or an empty result set.
• Asset pipeline break: build fails during deploy; caught in CI but can block a release if bundled at deploy time.

Ramp-up. A Laravel developer familiar with Nova is productive in under an hour — the API surface is a filter class, two props, and a scope. The ramp-up cost that matters is learning Nova's filter internals well enough to fix it when it breaks, which is a pre-existing investment for any Nova shop.

Recommendation. Adopt opportunistically, not strategically — unchanged in substance, strengthened in evidence. Pin to ^1.0.1, confirm the Composer package identity against the dcasia repository owner, internalise the fork immediately, and cap exposure to one or two resources where numeric range filtering is a frequent admin workflow. Where the workflow is occasional, a native preset-bucket SelectFilter delivers most of the value with none of the ownership burden. Do not let this become load-bearing, and revisit the decision at the next Nova major.