Product Decisions This Supports
- Build vs. buy for back-office admin tooling. Conditional field visibility is the classic hand-rolled glue: bespoke Nova callbacks, Alpine snippets, or copy-pasted JavaScript duplicated per resource. This package replaces that with a declarative wrapper inside the resource definition — an MIT-licensed, reversible dependency that buys back engineering time on a surface (internal admin) that rarely justifies custom code. The decision is "spend hours to save hours," not "invest a quarter in admin UX."
- Roadmap sequencing for admin usability. If support agents, ops, or sales live in the admin panel daily, conditional fields are among the cheapest usability wins available: shorter forms, fewer invalid submissions, less training, fewer "what do I put here?" tickets. Slot it as a sprint-sized improvement with an hours-scale rollback, not a strategic initiative competing with customer-facing work.
- Policy-as-configuration use cases. Hide "Refund reason" unless status is Refunded; reveal "Company VAT" only for business accounts; gate "Approval notes" behind an approval flag; suppress deprecated fields on legacy records. Each is a small operational policy that moves from code into a reviewable resource definition — diffable by a non-engineer.
- Feature-scope discipline. This is presentation-layer only: no change to validation, persistence, API contracts, or domain logic. Review, QA, and privacy/security surface stay contained, and the change is invisible to end customers.
- Dependency and vendor-risk calibration. 114 stars, zero dependents, last release May 2022, opportunity score ~30 — this is a single-maintainer utility, not infrastructure. The decision it informs isn't "is this strategic?" but "is this a contained, replaceable bet on a paid admin panel?" The answer is yes if compatibility is verified and a native fallback exists.
- Scope verification is the first decision, not the last. The supplied metadata contradicts itself: the repo, release notes, and prior assessments describe a Laravel Nova package, while the description blurb describes a Blade component (
<x-conditional-container>) with a Filament mention elsewhere. Confirm from composer.json and the README which framework and major version it actually targets before allocating any roadmap slot. If it doesn't match your admin stack, the decision closes in ten minutes — and the docs drift is itself a maintenance-quality signal worth weighing.
When to Consider This Package
Adopt only when all of the following hold:
- You run the framework it actually targets, verified from the repo rather than the summary, and your admin forms have a meaningful number of fields whose relevance depends on another field's value. Below roughly half a dozen such dependencies, native dependent-field behavior is simpler than adding a dependency.
- Compatibility is proven, not assumed. Your Nova/Laravel/PHP matrix is tested against the 2022-era release in staging. This is the gating check: a release two-plus years old against a fast-moving admin framework is the single most likely failure point, and stars or a composite score tell you nothing about it. Pin the exact version (
1.4.3), don't float.
- The behavior is non-critical. Visibility is UX convenience, never a security or data-integrity control. Hiding a field must never be the mechanism that enforces permissions or skips validation — both stay server-side, every time. Hidden does not mean absent from the request payload.
- You're comfortable with unmaintained-but-frozen. Single maintainer, no recent releases, zero dependents. Acceptable for admin UI where the exit cost is hours and someone on the team can read the field-rendering code; unacceptable if no one can patch a fork.
Look elsewhere when:
- Your admin stack isn't Nova. The Blade/Filament framing in the docs is drift, not a feature. A non-matching stack ends the evaluation immediately.
- Native Nova dependent-field behavior already covers your top two or three forms. Adopting a package for equivalent UX adds risk without adding capability.
- You need instant client-side reactivity across many fields. Closures here evaluate server-side at render; they won't re-run as the user changes the controlling field without a round-trip.
- The dependency is structural — nested containers inside
Repeater/Builder, or the visibility rule doubles as an access boundary. Split the case, or use a custom field.
- You need a support contract or predictable upgrade path. Nothing here offers that.
How to Pitch It (Stakeholders)
For executives — one paragraph. This is a small, reversible investment in the internal admin panel our operations team uses daily. It replaces hand-written, duplicated visibility logic with a documented convention, which shortens forms and reduces invalid submissions and training time. It costs engineering hours rather than weeks, carries no customer-facing risk, changes no data or API behavior, and can be removed by editing a handful of resource files. The caveats are honest: it's a single-maintainer open-source utility last released in 2022, so we verify compatibility with our exact framework versions before committing, and we treat it as a convenience layer — never as a security or validation control.
For engineering — the framing. Adopt as a presentation-layer convention, not a platform dependency. Gate the pilot on a verified composer.json check against our pinned Nova/Laravel/PHP versions, pin the release, and run one internal read-only resource for a sprint. Enforce server-side rules alongside every container (required_if, sometimes, nullable) and write the two guardrail tests: condition false with the field populated, and condition true with the field empty. Extract shared containers as resource methods so a fork, patch, or swap to native logic touches one seam per resource. Add "re-test conditional-container resources" to the Nova upgrade checklist, and budget a small fork-and-patch allowance before it's needed. If the pilot reveals framework incompatibility or unreliable nested-field behavior, we stop and revert — the cost of doing so is measured in hours.