Laravel Nova Conditional Container Laravel Package

Getting Started

Start by installing the package with Composer and checking the package README for the exact condition/container API exposed by your version:

composer require github-bishwajeet/laravel-nova-conditional-container

After install, look first at:

1. The package README for the ConditionalContainer import path and condition methods.
2. Any publishable assets/config tags in the package service provider.
3. A single Nova resource where you can isolate one conditional section.

If the package publishes assets, run the documented publish command and then clear Nova/cache:

php artisan vendor:publish --tag=laravel-nova-conditional-container
php artisan nova:publish
php artisan optimize:clear

The first practical use case is section-level visibility: show a “Billing Address” group only when billing_same_as_shipping is false, or show “Advanced Settings” only when a plan/status select reaches a certain value.

use GithubBishwajeet\LaravelNovaConditionalContainer\ConditionalContainer;

ConditionalContainer::make('Billing Address')
    ->dependsOn('billing_same_as_shipping', false) // confirm exact method in README
    ->fields([
        Text::make('Address'),
        Text::make('City'),
        Text::make('Postal Code'),
    ]),

Keep the first implementation narrow: one boolean/select condition, two or three fields, and test create/update flows before rolling it out to larger resources.

Implementation Patterns

Use the package as a form-layout and visibility tool, not as your validation or authorization layer. The strongest day-to-day patterns are:

• Group related conditional fields. Wrap a coherent section—billing address, shipping options, advanced settings—rather than scattering conditions across individual fields.
• Keep the controlling field outside the container. The field that drives the condition should be visible and reactive, typically a Boolean, Select, or similar Nova field.
• Pair visibility with server-side rules. If a field is required only when visible, encode that in the resource’s validation rules as well:

Text::make('VAT Number')
    ->rules('required_if:is_business,true'),

• Use for plan/status-dependent settings. For example, show “Enterprise Settings” only when plan is enterprise, or show “Refund Details” only after status becomes refunded.
• Use in multi-step or wizard-style forms. Conditional containers keep Nova forms manageable without building a custom Vue field.
• Keep conditions simple and declarative. Prefer direct equality/boolean checks over clever nested logic; Nova field dependency behavior is easier to debug when the condition is obvious.
• Test all resource actions. Check create, update, detail, and index views. Conditional containers usually affect forms most directly; do not assume they change index/detail rendering.
• Pin the package version in production. Since v1.0.2 is a patch-level release with no migration or breaking-change notes called out, treat it as safe to trial, but verify the changelog before upgrading across minor versions.

A typical resource pattern:

public function fields(NovaRequest $request)
{
    return [
        Boolean::make('Billing Same As Shipping', 'billing_same_as_shipping')
            ->default(true),

        ConditionalContainer::make('Billing Address')
            ->dependsOn('billing_same_as_shipping', false) // use documented API
            ->fields([
                Text::make('Billing Address', 'billing_address')
                    ->rules('required_if:billing_same_as_shipping,false'),
                Text::make('Billing City', 'billing_city')
                    ->rules('required_if:billing_same_as_shipping,false'),
            ]),
    ];
}

Gotchas and Tips

• Conditions are client-side UI hints. Always enforce required/visible-dependent logic in Laravel validation. A user can submit data that the UI would have hidden.
• Hidden fields may still be present in the request. Decide whether hidden values should be ignored, cleared, or validated. Use sometimes/nullable/required_if rules deliberately.
• Reactive fields matter. The controlling field must be one Nova can react to. If the container does not respond, check whether the dependency field type and field name match exactly.
• Nested containers/panels can be fragile. Keep the structure shallow when possible. If you nest conditional containers inside panels or other containers, test the full render path.
• Asset/cache issues after upgrades. After updating to v1.0.2 or later, republish assets if required and run php artisan optimize:clear / php artisan nova:publish. Stale compiled assets are a common source of “nothing changed” confusion.
• Field names vs. attribute names. Nova field labels and underlying attributes can differ. Use the same identifier in the condition that the controlling field actually submits.
• Do not rely on it for authorization. Conditional visibility does not replace Nova policies, field-level authorization, or canSee callbacks.
• Check detail/index behavior. If a hidden section should also be hidden outside forms, handle that in the resource’s field definitions or computed fields rather than assuming the container does it.
• Read the v1.0.2 changelog before upgrading. The release note only points to the full changelog; confirm there are no unpublished asset or API changes, then smoke-test one conditional resource in staging.