Inline Boolean Laravel Package

Getting Started

• Install with composer require dario-binalogue/inline-boolean. The package targets Laravel’s standard service-provider auto-discovery, so no manual registration should be required unless you have discovery disabled.
• First place to look is the package README.md, then src/ and any resources/views or config/ directory that gets published. Run php artisan vendor:publish --provider="DarioBinalogue\InlineBoolean\InlineBooleanServiceProvider" (check the exact FQCN in the README — provider naming is the most common source of copy/paste errors) and inspect what lands in config/ and resources/views/vendor/ before writing any code.
• Version 1.0.5 is a patch release with no documented behavioural changes — the changelog entry only links to the GitHub compare view (1.0.4...1.0.5). Treat this as a low-risk bump and confirm by reading the diff at that URL; it is almost certainly a bugfix, dependency bump, or style/typing change.
• Fastest first use case: take an existing admin index table with a is_active / published / enabled boolean column rendered as a static badge, and swap that cell for the package’s inline toggle. You get a one-click write with no full-page reload, which is the whole point of the package.
• Before you wire it up, confirm the persistence contract: which table/column does the toggle write to, and does it resolve the model by route key, by class + id, or via a callback you supply? That determines whether you can drop it into an existing resource controller or need a dedicated endpoint.

Implementation Patterns

• Blade-first rendering. The package is built around a small view component you drop into a table cell or detail page. Keep the surrounding markup dumb — pass the model (or an explicit model/id/field set of attributes) and let the component own the click handler.
• Dedicated PATCH route per resource. Rather than reusing your update endpoint, mount a narrow endpoint such as Route::patch('/admin/users/{user}/toggle/{field}', ...)->name('users.toggle'). Narrow endpoints keep authorization explicit and stop the toggle from tripping over unrelated $request->validate() rules on your full update form.
• Authorize in the endpoint, not the view. Hiding the toggle in Blade is cosmetic. Call $this->authorize('update', $model) (or a policy method specific to the field) inside the controller/action so a crafted request can’t flip a flag the user shouldn’t touch. This matters most for flags like is_admin, is_approved, or published.
• Model casts are non-negotiable. Ensure protected $casts = ['is_active' => 'boolean']; on the model. Without it, '0' from the request round-trips as a truthy string in Blade conditionals and you get a toggle that looks on when it’s off.
• Livewire pairing. If your table is a Livewire component, the idiomatic pattern is a wire:click="toggle({{ $model->id }})" action that does $model->update(['is_active' => ! $model->is_active]) and returns nothing — Livewire re-renders the single cell. If the package ships its own Livewire component, prefer it, but keep your own action as a thin wrapper so you can add audit logging.
• Optimistic UI + rollback. For Alpine/Turbo-driven front ends, flip the visual state immediately, then revert and surface a toast if the request fails (403/419/500). Boolean toggles are uniquely confusing when they silently fail — the user believes the record changed.
• Audit and events. Fire a domain event or write an activity-log entry from the toggle endpoint (PostPublished, UserDeactivated). Toggling is a state transition with business meaning, and you will want the trail when someone asks who unpublished a page.
• Bulk and filter ergonomics. Toggles pair badly with ->paginate() defaults if you don’t expose a where('is_active', true) filter alongside. Ship the filter and a “select all → bulk enable” action in the same pass, or users will click 40 toggles one at a time.
• Testing. Cover it with $this->actingAs($admin)->patch(route('users.toggle', $user))->assertRedirect(); $this->assertDatabaseHas('users', ['id' => $user->id, 'is_active' => false]); plus a 403 case for an unprivileged user and a 419 case if you rely on session CSRF from a custom fetch call.

Gotchas and Tips

• CSRF on hand-rolled fetch calls. If you bypass the package’s built-in request helper and use fetch(), remember X-CSRF-TOKEN from the <meta name="csrf-token"> tag. A 419 here renders as a “toggle does nothing” bug and eats an afternoon.
• Boolean column storage drift. MySQL tinyint(1) vs Postgres boolean vs SQLite integer — comparisons differ. If you ever query where('is_active', '=', true) on SQLite you can get surprising results; rely on the model cast rather than raw SQL literals.
• Mass-assignment and guarded fields. A toggle endpoint that does $model->update($request->all()) is both a security hole and a source of accidental writes. Whitelist the single field: $model->update([$field => ! $model->{$field}]), and validate $field against an allow-list so the route parameter can’t be used to flip arbitrary columns.
• Route-model binding + soft deletes. If the resource uses SoftDeletes, {user} binding won’t resolve trashed records — fine for most cases, but check that your restore/archive flows don’t expect toggles to work on trashed rows.
• Published views go stale. Once you vendor:publish the component views, package updates will not touch them. After bumping to 1.0.5 (and on every minor), diff the package’s original views against your published copies before assuming a rendering fix reached you.
• Version 1.0.5 is opaque. The release note is a bare compare link, which means no migration guide and no explicit “fixed X”. Pin to ^1.0.5 rather than ^1.0, and skim the compare diff for changes under src/ that touch request validation or authorization — those are the only plausible classes of change that could affect your endpoints in a patch.
• Extension points to prefer over forking. Config-driven model/field resolution and view publishing are the stable seams. If you find yourself editing files under vendor/, stop — wrap the package’s component in your own Blade partial instead, so a future 1.x release doesn’t overwrite your work.
• Missing pieces to fill yourself. A patch release almost never adds confirmation dialogs, undo, or rate limiting. For destructive-feeling toggles (is_banned, is_deleted-adjacent flags), add a confirm step client-side and throttle the endpoint; the package’s job is the write, not the safety rails.