Nova Switcher Laravel Package

Getting Started

Confirm the prerequisite before anything else. This is a Laravel Nova field, not a standalone package. Without a licensed Nova install it does nothing. The last release is 2023-11-01, i.e. the Nova 4.x era, and the repo is archived — so establish your Nova major first.

Step 1 — check whether you need it at all (5 minutes). Put Nova's first-party field on the resource and look at the index view:

use Laravel\Nova\Fields\Boolean;

Boolean::make('Active', 'is_active'),

On current Nova that already renders an inline, one-click toggle in index views. If that satisfies the requirement, stop — you have avoided an abandoned dependency for free. This is the highest-leverage step in the whole assessment.

Step 2 — read the source before you require it. Clone the repo and inspect two things:

• src/ — the PHP field class and its exact FQCN (typically a single class extending Laravel\Nova\Fields\Field with $component set to the Vue component name).
• dist/js/ or resources/js/ — the compiled Vue component. Note whether it is Vue 2 or Vue 3 shaped and which laravel-nova version it references. That tells you in a minute whether it will mount against your Nova build.

Step 3 — install pinned, or don't install at all. If you proceed:

composer require trin4ik/nova-switcher --with-all-dependencies

Then pin the exact resolved version in composer.json (e.g. "trin4ik/nova-switcher": "1.0.0") so a later composer update cannot resolve something else from a dead repo. Run php artisan vendor:publish for the assets.

Step 4 — first use case. Pick the most boring boolean on the most boring internal model — is_active on a Category, published on a Post, is_featured on a Product:

use Trin4ik\NovaSwitcher\NovaSwitcher; // verify FQCN from src/

public function fields(NovaRequest $request)
{
    return [
        ID::make()->sortable(),
        Text::make('Name'),
        NovaSwitcher::make('Active', 'is_active'),
    ];
}

Step 5 — verify empirically, not visually. Load the index, flip the switch, reload, confirm the DB column changed, and open the browser console. A blank cell with console errors is the single most likely first-run outcome for a custom field built against an older Nova.

Implementation Patterns

Index-first, detail-second. The entire value proposition is inline toggling from the index. Keep the field on both views by default; narrow it with standard Nova modifiers when needed:

NovaSwitcher::make('Active', 'is_active')
    ->onlyOnIndex()
    ->sortable(),

Remember Nova only renders index-visible fields on the index — if a resource hides fields with ->hideFromIndex(), the switcher will vanish with them.

Pair it with filters and lenses, not custom endpoints. The most useful day-to-day workflow is switcher on the index plus a BooleanFilter (or a lens) scoping the working set. Operators flip inline, the filter keeps the list clean, and you never write a route or controller:

// app/Nova/Filters/ActiveFilter.php
public function apply(Request $request, $query, $value)
{
    return $query->where('is_active', $value === 'true');
}

Model-side correctness is where the bugs live. The field writes through Nova's normal fill/update pipeline using the attribute name. Ensure the column is fillable and cast it:

protected $casts = [
    'is_active' => 'boolean',
];

With the cast, "1"/"0" round-trips cleanly and if ($model->is_active) behaves. Skipping the cast is exactly how "0"-is-truthy bugs appear.

Guard the cheap-but-expensive toggles. A single click that publishes content or pauses a subscription deserves validation and a hint:

NovaSwitcher::make('Published', 'is_published')
    ->rules('required', 'boolean')
    ->help('Publishes immediately on save.'),

Confirmation dialogs are not something this package provides — plan to build that into your own component rather than wrestling the archived one.

Treat it as a pattern reference for an owned field. The realistic long-term pattern: copy src/ and the Vue component into app/Nova/Fields or a private nova-components package, compile against your installed Nova, and reference your own class:

namespace App\Nova\Fields;

use Laravel\Nova\Fields\Field;

class Switcher extends Field
{
    public $component = 'switcher';
}

That is roughly half a day with php artisan nova:field and it keeps the dependency out of composer.json. Check the repo's license before vendoring — copying source is a licensing act.

Test the round-trip, not the pixels. Custom fields are presentation-only; protect against upgrade breakage with a resource test asserting a save persists the boolean:

$this->actingAs($admin)
    ->putJson("/nova-api/posts/{$post->id}", ['is_active' => true])
    ->assertOk();

$this->assertTrue($post->fresh()->is_active);

Gotchas and Tips

It is archived — plan for zero upstream. No fixes, no Nova-major compatibility work, no security patches. Pin the exact version, attach a named owner, and add "regression-check the switcher field" to your Nova upgrade checklist. An unowned custom field nobody remembers is how admin panels break at upgrade time.

The first failure is silent. A 2023 artifact built against Nova 4.x's asset pipeline may render blank on a newer Nova, or render but not save. The symptom is a dead control, not a stack trace. Open the browser console first — if the component errored on mount, no amount of PHP debugging will help.

Don't use it where a mistake is expensive. Internal admin flags, publishing queues, moderation state: fine. Billing, entitlements, permissions, anything customer-facing: no. Zero dependents means zero evidence anyone field-tested the edge cases, and nothing suggests keyboard semantics or ARIA state were validated. If you need accessibility conformance or localization, you will be building your own anyway — so start there.

Composer audit noise is a real cost. Archived packages emit "abandoned package" warnings that degrade signal-to-noise on genuine dependency risks and train teams to ignore composer audit. If you adopt this, handle abandoned-package ignores deliberately rather than living with the noise.

A switch is binary by construction. If your boolean is nullable and you want a third "unset" visual state, this field cannot express it. Default it (->default(false)) or move to a Select with Yes/No/Unset.

Extension points are the Nova field API, not this package. Label placement, colors, confirmation, conditional disabling — all of it goes through standard Nova mechanisms (->help(), ->rules(), ->canSee(), ->readonly(), dependsOn()). Assume the package surface is Field::make() plus a component name and nothing more.

The honest default. For new work on Nova 4/5: reach for Laravel\Nova\Fields\Boolean first, php artisan nova:field second, and this package essentially never. Its day-to-day leverage is real but small, and the maintenance obligation outlives the ergonomic win within one Nova upgrade cycle.