Blazor Component and Browser Notification API Interop Disposal and Permission

Implementation Strategy

To prevent repeated alerts and memory leaks, you must decouple the notification trigger from the component lifecycle using a JavaScript ES module and implement IAsyncDisposable to clean up references.

Permission Validation

Notification permissions should be cached at the JavaScript module level rather than validated inside every [JSInvokable] method. While checking Notification.permission is computationally cheap, caching the state reduces the overhead of repeated interop calls, particularly in Blazor Server where every call traverses a SignalR circuit.

Crucial Constraint: Browser security models prevent Notification.requestPermission() from being triggered automatically. It must be invoked via a user gesture (e.g., a button click). In Blazor Server, this means the interop call to request permission must originate from a UI event, not a server-side push.

Disposal Pattern across Hosting Models

To ensure JavaScript handlers are released regardless of whether you are using Blazor Server or WebAssembly, use the following pattern:

1. Import as Module: Use IJSObjectReference to import your notification logic as an ES module. This ensures the scope is isolated.
2. Implement IAsyncDisposable: The Blazor component must implement IAsyncDisposable. In the DisposeAsync method, call await jsModule.DisposeAsync().
3. JS-Side Cleanup: Within the JS module, provide a cleanup function that clears any active Notification objects or removes event listeners.

For Blazor Server, where circuits can disconnect abruptly, it is recommended to attach a beforeunload listener in JavaScript to trigger the same cleanup logic, as DisposeAsync may not always execute during an unexpected connection loss.

Recommended JSON Alert Schema

To maintain compatibility and minimize payload ambiguity, use a flat, primitive-based schema. Avoid passing complex .NET objects or DateTime types; use ISO strings instead.

{
  "title": "Alert Title",
  "body": "Detailed message content",
  "tag": "unique-notification-id",
  "icon": "/images/icon.png",
  "requireInteraction": false
}

The tag property is essential; it allows the browser to replace an existing notification with a new one rather than stacking multiple alerts, which directly solves the issue of repeated noise.

Verification Steps

• Permission Check: Verify in Browser DevTools → Application → Notifications that the state is correctly tracked.
• Leak Test: Navigate away from the component and trigger a notification; verify that no orphaned JS listeners are firing.
• Deduplication: Send two notifications with the same tag and confirm only one alert is visible.