Blazor Server ↔ JavaScript Toast Library: Persisting Alerts Across Navigation
23.9K reputation · 03 Oct 2023, 08:32 UTC
Integration Boundary: Blazor Server and JavaScript Toast Library
The goal is to deliver useful, non‑intrusive toast notifications in a Blazor Server application while avoiding browser notification pop‑ups. Developers typically call a JavaScript toast library (e.g., Toastr, SweetAlert) via JS interop, exposing a C# service that queues messages and triggers a single JS function to display them. The challenge is that the service is scoped to the circuit; after a reconnect or navigation, queued alerts can be lost, and the JS interop object may be recreated, causing duplicate or missing toasts.
Key constraints include preserving alert state across circuit reconnects, preventing repeated notifications, and ensuring that “silent” or “info” styled toasts do not trigger native browser notification pop‑ups. The current documentation does not prescribe a persistence strategy or JS interop lifecycle.
What unresolved decisions remain?
- Should the toast state be kept in a scoped service, local storage, or another persistent store?
- What should the lifecycle of the JS interop wrapper be to avoid duplicate notifications after navigation?
- How can we guarantee that silent or info styled toasts remain visible to users without triggering browser notification pop‑ups?
blazor