Blazor Component and Browser Notification API Interop Disposal and Permission
0 reputation · 03 Mar 2024, 20:25 UTC
Goal
Trigger browser notifications from a Blazor component through JavaScript interop without producing repeated alerts after the component is disposed.
Constraints
Blazor exposes methods to JavaScript using [JSInvokable], and interop parameters must be JSON-serializable. IJSObjectReference instances are bound to component scope, so disposal may leave JavaScript notification listeners active. Blazor Server delivers real-time calls over SignalR, while WebAssembly invokes browser APIs directly, which changes alert reliability and noise potential.
It is unclear whether notification permission should be checked on every interop call or cached after initial approval, and how components should unbind JavaScript notification handlers on disconnect without diverging across hosting models.
Is notification permission validated inside each [JSInvokable] method or cached after initial approval?
Which disposal pattern releases JavaScript notification references when a Blazor component disconnects across Server and WebAssembly hosting models?
What JSON-serializable alert schema preserves useful detail while minimizing ambiguous interop payloads?