Livewire Alert Laravel Package

Product Decisions This Supports

• Long-running action UX (build vs. buy): asLoading() + wire:poll + update() lets the server drive a persistent progress alert from PHP, so "Save", "Import", "Generate report", and Bus::batch() jobs can show real progress instead of a fire-and-forget toast. This is squarely a buy decision — the wrapper already abstracts SweetAlert2's showLoading() / update() / close() plumbing.
• Feature work now unblocked or cheapened: progress indicators on uploads/exports, multi-step wizards with in-place status text, "processing… → done/failed" transitions, polling-based status panels, background job kickoff confirmations.
• Roadmap sequencing: if your backlog already contains "add spinners to async actions" or "replace close-and-reopen toasts with live updates," this release converts those from custom-JS tickets into one-line PHP calls. Conversely, if your roadmap has no async/long-running flows, value is low.
• Scope/effort reduction: the alert state machine (open → loading → update → close) now lives server-side, which reduces frontend/Alpine work and keeps business logic in Laravel components — a meaningful reduction in cross-stack coordination for small teams.
• Use cases to prioritize: batch job progress, queued exports, AI/LLM generation waits, payment/webhook confirmation, multi-step forms, non-dismissable "do not navigate away" states.
• Risk items to log: the fluent update() does not merge config defaults — only explicitly-set options are emitted, so partial updates can behave differently than the initial show(); update() is a no-op with a console warning when no alert is visible, which needs graceful handling (not a user-facing error); asLoading() presets non-dismissable + backdrop-click-blocked, which needs a deliberate escape hatch plan for stuck jobs.

When to Consider This Package

Adopt when:

• You're on Livewire and already use (or plan to use) SweetAlert2-style alerts; this is the idiomatic wrapper and avoids hand-rolled JS bridges.
• You have server-driven or long-running flows — queues, batches, polling, multi-step server actions — where v4.2.0's asLoading()/update()/close() removes real UX friction.
• You want PHP-owned alert logic (testable, colocated with component state) rather than duplicated frontend state.
• You need a low-integration-cost upgrade: Alertable changes are additive, so v4.2.0 is a non-breaking bump — cheap to evaluate behind a flag.

Look elsewhere when:

• You're not on Livewire (Inertia/Vue/React SPA, Blade-only, API-first) — this wrapper's value is the Livewire binding; use SweetAlert2 or a JS toast library directly.
• You need toasts, inline validation, or component-level messaging rather than modal alerts — a notification/inbox system is a different product.
• You require accessibility-first, design-system-native components with strict tokens; a generic SweetAlert2 skin may not clear your a11y/design review.
• Long-lived server-driven UI is core to your product — at that point evaluate a purpose-built progress/status component rather than extending alert semantics.
• You need guaranteed delivery / durable notifications (email, persistence, read state) — this is ephemeral UI only.

Adoption checklist: confirm no third party implements Alertable (new interface methods require implementation despite "additive" framing); verify behavior in a non-dismissable loading state when a job hangs or the request fails; confirm wire:poll cadence won't overload your queue/DB; document the "no visible alert" no-op path so update() calls after navigation fail silently.

How to Pitch It (Stakeholders)

For executives: Version 4.2.0 turns our alert dialogs from static pop-ups into live status surfaces, driven entirely from the backend. In practice, that means users see a real progress indicator while imports, exports, payments, and background jobs run — instead of a toast that vanishes or a spinner we'd otherwise hand-build. It's a non-breaking patch to an existing dependency, so cost is near zero and it removes a known class of "did it work?" support tickets and premature re-submissions.

For engineering: Three additive methods on Alertable — asLoading() (non-dismissable preset + Swal.showLoading()), close(), and update() (fluent or explicit payload, backed by Swal.update()) — give components direct control of an open alert without close-and-reopen flicker. No breaking changes, no migration. Two behaviors to design around: fluent update() emits only explicitly-set options (no config-default merge), and update() when no alert is visible is a silent no-op with a console warning. Recommend wrapping the asLoading() → update() → close() sequence in a small helper with a failure/escape path, and adding a test that asserts the alert closes on job completion and on exception. Release notes have minor typos (e.g. "spinne", "calal") and an inconsistent changelog compare link — cosmetic, but worth a docs PR if we're pointing other teams at this.