Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Inline Boolean Laravel Package

markrassamni/inline-boolean

A Laravel Nova field for toggling boolean values directly from resource index and detail views. It provides a compact inline switch, customizable on/off labels, and quick updates without opening a separate edit form. Useful for publishing, enabling, or approving records in one click.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Verdict (TPM read): low opportunity (1.86) is correct — do not adopt as a runtime dependency; treat it as a ~200-line reference design.

  • Architecture fit: This is a Laravel Nova field package, not an application library. It slots into a resource's fields() method and ships a Vue IndexField/DetailField component that renders an inline toggle and calls Nova's update endpoint. Architecturally it is thin and clean — presentation-layer only, no schema changes, no service layer, no data model of its own. That is also its limit: its entire value is glue code against Nova internals, which is exactly the layer most exposed to framework churn.
  • Integration feasibility: Composer install is trivial only inside an app that already holds a licensed laravel/nova dependency. Outside a Nova stack it is dead weight; inside a modern Nova stack it almost certainly will not resolve, because the release history stops in June 2019 (Nova 2.x / Vue 2 tooling), while Nova 4+ moved to Vue 3 and Inertia. Expect a version conflict or a blank/broken index column rather than a clean failure.
  • Technical risk: Moderate-to-high for what should be a trivial feature. Archived repository means zero upstream fixes; no visible test suite; unknown behavior on authorization (does the inline PATCH still traverse Nova's update policy and field-level visibility rules?) and on concurrency (does it send an absolute target value or a blind toggle — the latter causes last-write-wins flip-flopping when two admins click). Vue 2 asset tooling is end-of-life and a supply-chain consideration on its own.
  • Key questions:
    1. Which admin layer are we actually standardizing on — Nova (and which major), Filament, or bespoke? Nova 4/5 invalidates this package outright.
    2. Is inline boolean editing a hard requirement or a convenience? The feature is ~1 PHP field class plus ~1 Vue component to rebuild.
    3. Do toggles need an audit trail (who flipped it, when) and per-record authorization? A third-party field may bypass both.
    4. What is our exit cost if the maintainer never returns? (Answer: we already own it — the repo is archived.)

Integration Approach

  • Stack fit: Narrow. Laravel 5.x/6.x + PHP 7.1+ + Nova 1.x/2.x + Vue 2 is the only supported matrix. If the platform roadmap includes Nova 4/5, Filament, or a custom admin, fit is effectively zero.
  • Migration path: Do not composer require. Fork or, better, reimplement: copy the field class pattern into app/Nova/Fields/InlineBoolean.php, rewrite the front-end as a Nova 4/5-compatible component (or Filament's ToggleColumn, which is a native one-liner today), and wire it through Nova's existing update route so policies and validation apply unchanged.
  • Compatibility: Pin nothing to the package. Validate against our actual Nova/Laravel/PHP versions in a spike before any code is written; the 2019 constraint set will not satisfy a current stack.
  • Sequencing:
    1. Confirm admin platform and Nova major version (gate — if not Nova 2.x, stop).
    2. Timebox a half-day spike reproducing the toggle natively in one resource.
    3. Add authorization + audit assertions (policy check on update, log entry on change).
    4. Decide absolute-value vs. toggle semantics; prefer absolute to avoid race flips.
    5. If adopted at all, vendor the code into our repo with a named owner — never depend on the archived package.

Operational Impact

  • Maintenance: Zero upstream. Every Nova upgrade becomes our migration, and Nova majors land roughly every 18–24 months. Cost is small (one field class, one component) but recurring and unplanned unless we own it deliberately.
  • Support: None. No issue triage, no security response, no maintainer to escalate to. Internal documentation is the only support surface — write a one-pager when we port it.
  • Scaling: Not a throughput concern — single-row PATCH on a boolean. The one real scale caveat is bulk editing: an index-page "toggle all" pattern issues N requests, which is a poor fit for large admin tables. Cap it or add a bulk endpoint.
  • Failure modes: (a) Silent break on Nova major — component fails to render, column appears empty, no error surfaced; (b) authorization bypass if the inline route skips Nova policies; (c) race conditions from toggle semantics; (d) asset build failure from dead Vue 2 tooling. Mitigate with a smoke test on the resource index and a policy test on the endpoint.
  • Ramp-up: Low for any Laravel developer with Nova exposure — roughly half a day to a day to reimplement and test natively. The constraint is not skill, it is the decision to own a small piece of UI code rather than inherit an abandoned one.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
coleus/frame
thtg88/journalism
filagora/filagora-ai-forums
rlacerda83/query-parser
socialdept/atp-orm
cboxdk/laravel-assistant-client
socialdept/atp-resolver
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings