{{-- Replaces the legacy App\Helpers\Flash::render() — these pages use Laravel's own session for flash messages (see the Phase 2 plan), not the legacy session. --}} @foreach (['success' => 'alert-success', 'error' => 'alert-danger', 'warning' => 'alert-warning', 'info' => 'alert-info'] as $flashType => $alertClass) @if (session($flashType)) @endif @endforeach {{-- Shared handler for "confirm, delete/approve one row, don't reload the page" forms (Phase: AJAX-ify confirm-then-redirect forms). Opt in per-form via class="js-ajax-form"; the controller action must branch on the X-Requested-With header and return JSON ({success, message, ...extra}) instead of its normal redirect when present — every non-AJAX caller keeps working exactly as before. data-remove-target: CSS selector for the element to remove from the DOM on success (defaults to "tr"). Resolved via form.closest(...) — the usual case of a form nested inside the row it deletes — unless the selector starts with "#", in which case it's resolved via document.querySelector(...) instead, for the rarer case where the form lives outside the row it controls (e.g. a hidden form linked to its button only via the button's form="..." attribute). data-replace-target: alternative to data-remove-target for forms whose action changes rather than removes content (add/edit/reorder) — the server returns a re-rendered HTML fragment as data.html, and that fragment replaces the target element's outerHTML instead of removing it. Same "#"-prefix vs. closest(...) resolution rule as data-remove-target. If the submitting form sits inside a currently-open Bootstrap modal (edit/add dialogs), that modal is hidden first and the DOM swap waits for its 'hidden.bs.modal' event — swapping immediately would tear out the modal element mid-transition and leave its backdrop stuck. data-alert-target: optional selector for a container to show inline success/error feedback in. Respects e.defaultPrevented so a sibling onsubmit="return confirm(...)" handler that already cancelled the event (user clicked Cancel) stops this from firing too — per spec, an onsubmit returning false calls preventDefault() but does not stop other submit listeners from running, so this check is required, not defensive-for-no-reason. Pages needing extra DOM sync beyond "remove this row" (running totals, pending-count badges, etc.) listen for the bubbling 'ajax-form:success' event on the form and patch their own page-specific bits from event.detail. A controller may also answer {success:false, needsConfirm:true} instead of {success:true/false, message} — see the needsConfirm branch below for why and what happens (real form.submit() fallback, no JSON round-trip on the resubmit). --}} @yield('content')