Nova Modal Response Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel feedback UI. Nova actions can return a toast, a download, or a redirect — but nothing content-rich without custom Vue/Blade work. This package answers "do we commission a modal component?" with no, for read-only informational modals. A typed block model (text, headings, lists, dividers, code, JSON, markdown, Blade views, badges, icons, links, inline rows, collapsibles, tabs) covers structured display without a frontend initiative, which keeps the cost of small operational features inside the backend team's capacity.
• Scope boundary as an explicit product line, not a judgment call each time. Buy for static or structured display; build only when the requirement is genuinely interactive — multi-step wizards, forms that submit from inside the modal, live filtering, stateful editing. Publishing that line up front stops "just add a button to the modal" scope creep, which is where this package stops and custom work begins.
• Feature decisions to surface outcomes, not just confirmations. Any action whose result a user must read becomes a candidate for an in-context modal instead of an emailed report or a custom results page: import/export reports, sync diagnostics, generated scripts, API payloads, validation warnings. This is a recurring, low-cost surface for product value — copyable code and JSON blocks in particular remove real support friction in debugging workflows.
• Roadmap sequencing for support and operations tooling. Release notes, changelogs, runbooks, troubleshooting flows, and tabbed in-admin documentation are typically quarter-level "nice to haves." The v2 block stack makes them cheap enough to slot into a sprint rather than a project, which changes their priority ranking.
• Prioritization signal from the API surface. v2 added tabs, collapsibles, markdown, Blade views, and shared Size/Variant/Alignment enums. That indicates the maintainer's direction is content composition, not interactivity — so roadmap bets should lean toward documentation and diagnostics surfaces, not toward making this a workflow engine.
• Upgrade planning as a sized product input. v2 is a breaking major: the payload changed to { title, size, closeButtonText, blocks: [...] } and withoutSyntaxHighlighting() was removed. Apps using only the ModalResponse PHP API usually just bump the dependency; anything constructing Action::modal('modal-response', [...]) directly needs scoped migration. Budget it as an explicitly-sized technical item with QA on every modal-returning action — not a background chore.
• Adoption risk entered into the risk register, not treated as a blocker. ~17 stars, zero dependents, single primary maintainer: this is a convenience dependency, not an ecosystem standard. Acceptable for internal admin tooling precisely because the fallback (fork, vendor, or a handful of Blade views) is cheap. Do not let it become load-bearing for customer-facing surfaces.

When to Consider This Package

Adopt when most of the following hold:

• You already run Laravel Nova for internal or back-office admin — the package has zero value outside Nova.
• You need consistent, content-rich informational modals built from typed blocks rather than hand-rolled HTML, and you want that composition standardized across teams.
• You want code and JSON presented properly — syntax highlighting, per-block highlighting control, language hints, copy-to-clipboard, including nested inside collapsibles and tabs. This is the most concrete win over a plain text response.
• You want structured layout without frontend work: tabs, collapsibles, badges, icons, links, inline rows, dividers, markdown, and server-rendered Blade views in one modal.
• You are on v1 and primarily use the ModalResponse fluent API — the upgrade is likely a dependency bump plus visual QA.
• You will commit to one golden-payload test so a future v3 cannot silently break your modals.

Defer or look elsewhere when:

• You are not on Nova, or need framework-agnostic or customer-facing UI.
• You need interactive modals — forms, wizards, in-modal mutations, live data. The block model is a render surface, not an interaction model.
• You build payloads via Action::modal('modal-response', [...]) and cannot schedule migration work; v2's payload break is signalled only by a console.warn — no PHP exception, no failing test unless you assert the shape.
• You have published or customized the package's views/assets and lack an owner to re-publish and diff them. Stale compiled assets against a new payload contract is the most likely real-world failure mode.
• You pass user-controlled or AI-generated content into markdown, html, or view blocks — these render unsanitized (Markdown preserves javascript: links and most raw HTML). Use text, list, or code for untrusted input, or confirm a sanitization layer first.
• You need vendor support or a maintenance guarantee. Small MIT package; plan for self-sufficiency.

How to Pitch It (Stakeholders)

Executives. This standardizes how our admin panel communicates results to internal teams — import reports, sync diagnostics, release notes, troubleshooting content — without a custom frontend build. The value is less bespoke code and faster delivery of small operational features. The cost is a contained upgrade: it is a major version, but the break is narrow and identifiable (hand-built modal payloads and one removed deprecated method), typically well under two engineering days plus QA. The dependency is small and single-maintainer, which is acceptable here because it is confined to admin UI and cheaply replaceable.

Engineering. This is a Nova action response that emits a JSON payload rendered by a bundled JS/Vue renderer. v2 replaces the single-body render path with an ordered stack of typed blocks built through a Block factory and ModalResponse::stack(), with Size/Variant/Alignment enums. The ModalResponse fluent API keeps working; the breaking change is the payload shape for direct Action::modal calls plus the removal of withoutSyntaxHighlighting(). Because the failure mode is a silently empty or partial modal rather than an exception, migration needs four concrete steps: grep for raw payload construction and the removed method, re-publish or rebuild front-end assets in the same release as the Composer bump, add a golden-payload assertion, and manually open every modal-returning action in light and dark mode — including one nested collapsible and one tab set — watching the console for legacy-key warnings. If Laravel Boost is in use, upgrade Boost to ≥1.3.0 before the package. Record v1.3.0 as the rollback target and treat code plus assets as one atomic unit. Internal convention: view blocks render repo-controlled Blade only; markdown comes from static strings, never request input.

Product. Prioritize use cases where the block model pays for itself immediately: post-action diagnostics with copyable code and JSON, changelog and release-note modals using headings, lists, and badges, documentation organized into tabs, and collapsible troubleshooting steps layered with runbook links. Compose these from markdown and Blade views rather than commissioning custom modal UI, and resist scope creep toward interactive forms — that is where this package stops and custom work begins. Schedule the v2 upgrade as a small, explicitly-scoped technical item with QA coverage on existing modal flows, and log the dependency's low adoption and single maintainer as a standing assumption in the risk register rather than a blocker.