Weave Code
Nova Dependency Container Laravel Package
epartment/nova-dependency-container
Laravel Nova package that adds a dependency container for conditionally showing or hiding groups of fields. Use dependsOn() to react to another field's value, keeping forms dynamic and clutter-free without custom JavaScript. Ideal for building cleaner, context-aware Nova forms.
A Laravel Nova field container allowing to depend on other fields values
Frequently asked questions about Nova Dependency Container
- How do I install epartment/nova-dependency-container in a Laravel Nova app?
- Run composer require epartment/nova-dependency-container and then use the DependencyContainer field inside your resource's fields() method, wrapping the child fields you want to hide or show. Because Laravel Nova is a commercial package that is usually not declared as a hard Composer dependency, your local environment and CI pipeline need Nova license credentials configured before the install will resolve. There are no migrations, service providers, or config files to publish.
- Does epartment/nova-dependency-container work with Laravel Nova 4 or Nova 5?
- No. Version 1.3.3 explicitly targets Nova 3.x, and there is no indication the package has been ported to Nova 4 or Nova 5. It ships precompiled Vue 2-era assets, which are likely to break or behave inconsistently on newer Nova majors, and you cannot patch those assets without forking the package. If your estate is on Nova 4 or later, evaluate Nova's native dependsOn() instead of adopting this package.
- How does the dependsOn() method work in a Nova dependency container?
- You wrap a group of fields inside a DependencyContainer and call dependsOn() with the name of a sibling field and the value it should match. When the sibling field's value changes in the browser, the container conditionally renders or hides its children using Vue, so forms stay context-aware without hand-written JavaScript. The dependency definition lives in your PHP resource file, but the actual show/hide enforcement happens client-side.
- Can I nest dependency containers or use multiple conditions?
- The package's model is essentially equality-based, single-level dependencies, so multi-condition, deeply nested, or relational-field dependencies exceed what it cleanly supports. If your forms need compound logic or dependencies across relationships, verify the behaviour carefully in a spike before committing. For simpler cases, keep containers flat and avoid stacking them where possible.
- Does the dependency container affect server-side validation rules?
- No. Hiding a field via the container is enforced only in Vue, so your PHP validation is unaffected and your rules() method will still run against hidden fields unless you author conditional rules separately. The most likely source of bad data is divergence between the visual dependency graph and the server-side rules, so mirror every dependency in rules() and document the convention. Treat client-side visibility as a UX concern, not a validation boundary.
- What happens to hidden field values when a record is saved or updated?
- Fields removed from the form by Vue's v-if are not submitted with the request, which means an update can null out or overwrite previously stored values depending on how your resource's save and fill behaviour works. This needs explicit testing rather than assumption, especially on edit forms where a user toggles a dependency after values already exist. If hidden fields must retain their stored values, add server-side handling to preserve them.
- Can I use dependency containers in fieldsForIndex and fieldsForDetail?
- Yes, as of version 1.3.3. That release fixed behaviour in fieldsForIndex and fieldsForDetail, so the same container definition can be reused across form, index, and detail contexts instead of being confined to forms. If you previously worked around the bug, you can drop the workaround, but re-verify any resource that defines containers in those contexts after upgrading.
- What are the alternatives to epartment/nova-dependency-container?
- The main alternatives are Nova's native dependsOn() and hideWhen() helpers, or writing custom Vue components if your logic exceeds what those offer. Native dependsOn() covers equality-only conditions and single-level nesting, which is enough for many forms and removes a third-party dependency entirely. On Nova 4 or later, native dependsOn() is the recommended path because this package has not been ported.
- Is epartment/nova-dependency-container actively maintained?
- It has a single maintainer with no predictable release cadence. The 1.3.3 patch shows the project is not abandoned, but you should treat it as vendored code you own rather than a supported dependency. Budget time for forking if you need to patch precompiled assets or add Nova 4/5 support yourself.
- How should I test forms that use dependency containers before production?
- Cover three areas explicitly: that hidden fields are excluded from submission as expected, that existing stored values are not accidentally nulled on update, and that your server-side rules() mirror the same dependency logic. Also test the container in fieldsForIndex and fieldsForDetail if you use them, since that behaviour was only patched in 1.3.3. Feature tests around the save path plus a manual pass through each resource form are usually enough to catch divergence.
Weaver
How can I help you explore Laravel packages today?