Nova Dependable Panel Laravel Package

Getting Started

formfeed-uk/nova-dependable-panel adds conditional ("dependable") panels and fields to Laravel Nova — you declare that a field or group of fields should only be shown, hidden, disabled, or required based on the current value of another field on the same form.

composer require formfeed-uk/nova-dependable-panel

There is nothing to publish or migrate; the package is registered through Nova's normal package discovery. Requirements are a supported Nova major version plus the matching PHP/Laravel range declared in the package composer.json — check that first, since Nova major bumps are the usual source of breakage.

Where to look first:

1. The package README for the canonical DependablePanel example — it is short and is the fastest way to understand the mental model.
2. src/ for the panel class and any field/trait classes; the dependency resolution logic lives there, and reading it once will save you hours of guessing about dot-notation and array handling.
3. Your own app/Nova/*.php resources — start by converting a single group of fields on one resource, not a whole form.

First use case: a Select field (type) that should reveal a different set of fields depending on whether the user picks "person" or "company". Wrap the conditional fields in a dependable panel, point the panel at type, and give each branch its matching value. Confirm the fields appear/disappear as the select changes, then confirm server-side validation still runs when the fields are hidden.

Implementation Patterns

Group, don't scatter. The natural unit of work is a panel containing fields that share a condition. Wrapping five fields in one dependable panel is easier to read and cheaper to resolve than attaching the same condition to five individual fields.

Keep the dependency source stable. Depend on fields that are always present in the form payload (a Select, Boolean, BelongsTo), not on fields that are themselves conditionally hidden — chained dependencies work, but they multiply the states you have to reason about and make debugging much harder.

Dot notation for nested values. When a dependency points at a nested attribute (for example a value inside a JSON/meta field or a BelongsTo pair), refer to it with dot notation and verify the resolved value in the browser devtools network payload when it does not behave as expected.

Closures for anything non-trivial. For conditions that are more than "equals this string" — ranges, in_array, multi-field combinations — express the condition in a closure so the logic is testable and readable, rather than nesting panels.

Pair with real validation. Conditional visibility is a UI concern only. Any field that becomes required when visible must also be conditionally required in the rules() method of the corresponding NovaRequest; otherwise a crafted request bypasses your intent. Consider a small helper on the request that mirrors the same condition used in the panel so the two cannot drift.

Reuse across resources. If the same trio of fields appears in Create and Update (which it usually does, via fields()), define the fields once in a private method or a trait and call it from both. Dependable panels compose fine with ->onlyOnForms() / ->exceptOnForms() and with Panels nested inside other containers.

Version-pin if you depend on edge behaviour. This is a small, single-maintainer package with patch releases that touch resolution internals; a ~1.2.0 constraint is a sane default, and you should skim the changelog before bumping.

Gotchas and Tips

• Hidden fields still submit (or don't). Nova's behaviour for hidden fields has changed across versions. If a value is hidden but still present in the payload, server-side conditions may evaluate differently from what the UI shows. Test the actual submitted payload, not just the rendering.
• Array keys are the known weak spot. 1.2.3 is precisely a fix for "issue with array keys" in dependency resolution. If you were on 1.2.2 or earlier, re-test any dependency whose source value is an array or an associative structure (multi-select, keyed options, nested meta) — those are the cases that were mis-resolving. After upgrading, clear Nova's compiled assets/caches (php artisan nova:publish --force if you have published assets, plus php artisan view:clear) before concluding anything is still broken.
• Numeric vs. string comparisons. Select values arrive as strings; booleans arrive as booleans. A dependency on true will not match "1" in every code path — normalise in a closure if you are unsure.
• Don't mix with Nova's native dependsOn carelessly. Nova's built-in field dependency feature and this package solve overlapping problems; using both on the same field can produce contradictory visibility rules that are painful to trace.
• Empty values silently fail closed. If the source field is absent from the form data (new resource, field not yet rendered, field in another tab), the dependency usually evaluates as "not matched" and the panel stays hidden. If a panel is mysteriously invisible on create but fine on update, this is nearly always the cause.
• Debugging. Temporarily attach a plain Text field bound to the same attribute next to the dependable panel to see the live value; and log the resolved dependency inside a closure. There is no dedicated debug mode.
• Extension points are limited. The package is small and not designed for heavy subclassing; prefer composing panels and closures over extending internal classes, which are the most likely thing to change in a patch release.
• Testing. Unit-test your condition closures directly rather than relying on Dusk for visibility; reserve browser tests for one smoke test per resource to catch regressions after Nova or package upgrades.