- What is markwalet/nova-modal-response used for?
- markwalet/nova-modal-response is a Laravel Nova asset that lets Nova actions return modal responses instead of only one-line confirmations. You can show custom content, confirmations, messages, diagnostics, reports, or payloads in a modal without leaving the admin page. It is purely presentation-layer tooling and has no value outside Laravel Nova.
- How do I install markwalet/nova-modal-response in a Laravel Nova app?
- Install it as a Composer dependency in a Laravel Nova application and publish or compile the bundled front-end assets. There are no migrations, config coupling, infrastructure provisioning, or data-model changes. Treat the Composer package and its compiled assets as one atomic unit in the same pull request.
- Does nova-modal-response require Laravel Nova, and which Laravel/Nova versions are supported?
- Yes, Laravel Nova is a hard prerequisite; the package has zero value outside Nova. The provided evaluation treats v2 as the strategically relevant version, but you should confirm exact Laravel and Nova version constraints in the package composer.json and release notes before adoption. If you use Laravel Boost, upgrade Boost to 1.3.0 or later before bumping this package.
- How do I return a modal response from a Nova action?
- Return a ModalResponse from your Nova action's handle method using the package's PHP fluent builder. The builder emits a JSON payload that the bundled JavaScript/Vue renderer displays inside a Nova action modal. Apps that only use the ModalResponse fluent API usually just bump the dependency during upgrades.
- What content blocks can I render in a Nova modal response?
- v2 supports an ordered stack of typed blocks including text, headings, lists, dividers, code, JSON, HTML, markdown, Blade views, badges, icons, links, inline rows, collapsibles, and tabs. Blocks share Size, Variant, and Alignment enums, which makes the output more consistent than a single string body. This typed model is what makes it usable as a team-wide standard for admin messaging.
- What are the breaking changes when upgrading nova-modal-response to v2?
- The v2 breaking surface is narrow: hand-built Action::modal('modal-response', [...]) payloads now use { title, size, closeButtonText, blocks: [...] }, and withoutSyntaxHighlighting() was removed after being deprecated since v1.1.3. Apps using only the fluent ModalResponse API usually just bump the dependency. Budget roughly 0.5–1.5 dev-days for grep, fixture updates, and per-modal visual QA, and add about one day if published views/assets or bespoke JavaScript touch the payload.
- Why does my Nova action modal appear empty or partial after upgrading?
- The most common cause is a v1 payload being rendered by the v2 renderer, which can degrade to an empty or partial modal with only a console.warn. There is no PHP exception and no failing test unless you assert payload shape, so use a golden-payload test and a manual QA pass. Also confirm that Composer was bumped and the published/compiled assets were rebuilt in the same release.
- How should I test a Nova action that returns a ModalResponse?
- Add a golden-payload test that asserts the JSON shape your action returns, especially title, size, closeButtonText, and blocks. Because a v1 payload against a v2 renderer can fail silently, payload-shape assertions matter more than simply calling the action. Pair that with a per-modal visual QA pass for actions that users must actually read.
- Is it safe to render HTML, markdown, or Blade views from nova-modal-response?
- No, markdown, HTML, and view blocks render as given, so treat them as unsanitized render surfaces. Markdown can preserve javascript: links and most raw HTML. Establish an internal convention: view blocks render repository-controlled Blade only, markdown comes from static strings, and untrusted or AI-generated content uses text, list, or code blocks or passes through a sanitization layer first.
- Does nova-modal-response support multi-step wizards or forms, and what if I need an alternative?
- Multi-step wizards, in-modal forms, live filtering, and stateful editing are out of scope; this is a render surface, not an interaction model, so those are build decisions rather than package decisions. The project is small, with roughly 17 stars, zero dependents, and a single primary maintainer, which is acceptable because the fallback is cheap: fork, vendor, or use a handful of Blade views. Keep that maintainer concentration in the risk register as a standing assumption, not an approval blocker.