Nova Switch Laravel Package

Getting Started

ferdiunal/nova-switch is a Laravel Nova field package that renders a boolean attribute as a toggle switch instead of Nova's stock checkbox/Boolean field. It is a small, single-purpose package: install it, drop the field into a resource, and you get a more legible on/off control in forms and (where supported) on the index.

Minimal steps

1. Require it alongside Nova (it is a Nova field, so laravel/nova must already be installed and licensed):

   composer require ferdiunal/nova-switch:^1.0
   

   There is typically no service provider registration, no config file to publish, and no migration — Nova 4+ auto-discovers the field and serves the compiled Vue component from the package's dist/ directory.
2. Add the field to a resource's fields() method:

   use Ferdiunal\NovaSwitch\NovaSwitch;
   
   public function fields(NovaRequest $request)
   {
       return [
           ID::make()->sortable(),
           Text::make('Name'),
           NovaSwitch::make('Active', 'is_active')
               ->rules('boolean')
               ->default(false),
       ];
   }
   

3. php artisan nova:assets (or just hard-refresh) if the toggle renders as a blank cell — Nova caches the field manifest and a stale manifest is the usual cause of "unknown component".

Where to look first

• The package README.md for the exact class/namespace and any fluent modifiers it exposes (trueLabel/falseLabel, onColor/offColor, inlineOnIndex, etc. — the available set varies by minor version, so read the source rather than assuming).
• vendor/ferdiunal/nova-switch/src/ — the field class is a handful of lines; it tells you the $component name and every overridable property in one read.
• vendor/ferdiunal/nova-switch/resources/js/ — the Vue component, if you need to confirm behaviour on the index vs. detail vs. form views.

First use case — replacing Boolean::make('Active') on an is_active column for a model where activation is toggled frequently by admins (users, feature flags, published toggles). The switch is easier to scan in a long index list than a checkbox, and if the package supports index-toggling it removes a full edit round-trip.

Implementation Patterns

Pair it with a real cast. The field only renders a boolean; persistence is your model's job.

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

Index vs. form placement. Use Nova's standard visibility modifiers to keep dense indexes readable:

NovaSwitch::make('Active', 'is_active')
    ->sortable()
    ->rules('boolean')
    ->hideWhenCreating()   // if the column defaults to false in the DB
    ->hideFromDetail();    // switch adds nothing on the read-only detail view

Filtering and sorting stay with Nova's own primitives. The package provides an input component, not a filter. Pair it with a BooleanFilter (or a SelectFilter over 'Active' => 1, 'Inactive' => 0) so the index toggle has a companion way to narrow results. Always add ->sortable() explicitly — Nova does not infer it, and sorting an un-indexed boolean column is fine but sorting a computed accessor is not.

Nullable tri-state. For columns that may be null (e.g. is_approved before review), add ->nullable() on both the field and the DB column; without the DB-level nullability the switch will coerce null to false on save and silently change semantics.

Inline actions and modals. The field is a normal Nova field, so it works in action fields, Lens definitions, and Nova 4 panel layouts unchanged:

Panel::make('Settings')->addFields([
    NovaSwitch::make('Active', 'is_active'),
]),

Customising appearance / behaviour. Every Nova field is subclassable. If you need a different component, extra props, or a custom resolver, extend the field and set $component (or override resolve()/fill()), then point your resource at your subclass. This is the intended extension point and is far more stable than forking the package.

Testing. Don't assert on the rendered switch in PHPUnit — assert the underlying model/endpoint. For the UI, a Dusk or Pest browser test that clicks the toggle and re-fetches the resource is the only reliable check that the save path works, because a misconfigured policy or missing cast will fail silently in the UI.

Gotchas and Tips

• v1.0.1 is a patch release with no published notes. The release body is only a compare link (v1.0.0...v1.0.1). Treat it as safe to upgrade from v1.0.0 — no breaking changes are signalled by the semver bump — but open the compare link before upgrading production, and pin ^1.0 rather than * so future patches arrive predictably.
• Namespace/class name drift. Nova switch packages in the wild are variously NovaSwitch, SwitchField, and Toggle under different vendor namespaces. Copy the use statement from the README or from src/ rather than guessing; an unresolved class is the single most common install failure here.
• Policy checks gate inline toggling. A switch rendered on the index is only writable if the update ability passes for that resource. If the toggle appears but does nothing, check the policy before you check the package.
• Stale Nova assets after upgrade. After bumping the package version, run php artisan nova:assets (or nova:publish) and clear config:cache/view:cache. A blank column or a plain text input instead of a switch almost always means the manifest still points at the old build.
• Not a validation layer. ->rules('boolean') accepts 1/0/true/false and rejects "on"; if you're sending values from a custom component or API, normalise before validation rather than loosening the rule.
• Nova major-version compatibility. The package targets Nova 4.x. If you upgrade to Nova 5, verify the Vue component still mounts before relying on it — small field packages are frequently the first thing to break across a Nova major.
• Don't use it for multi-value flags. It maps 1:1 to a single boolean column. For enum-like state (draft/published/archived) reach for Select or Status; shoehorning a tri-state into a switch via nullable() gets confusing for users fast.
• Debugging render issues. Vue errors from Nova fields surface in the browser console, not the Laravel log. Check the console first, then nova-components/dist in vendor/, before assuming the backend is at fault.