EventSource

Returns true when the runtime exposes EventSource. Supported by every current engine. During prerender/SSR the check returns false rather than throwing, so defer it to OnAfterRenderAsync.

@inject Bit.Butil.EventSource eventSource

var supported = await eventSource.IsSupported();

Named events never reach the default message listener, so anything the server names has to be declared in eventNames to be seen at all. The onError callback's argument distinguishes 'the browser is about to retry' (false) from 'this stream is finished' (true) - the browser reconnects on its own by default, so a transient failure is not something you have to handle.

private EventSourceHandle? _stream;

_stream = await eventSource.Open(
    "/sse/ticks",
    onMessage: e => InvokeAsync(() =>
    {
        // e.EventName is "message" for unnamed events, the server's name otherwise
        // e.Data is always text - deserialize it yourself
        // e.LastEventId is what the browser replays on reconnect
        _events.Insert(0, e);
        StateHasChanged();
    }),
    eventNames: ["heartbeat"],
    onOpen: () => InvokeAsync(StateHasChanged),
    onError: fatal => InvokeAsync(StateHasChanged));

// closing is what stops the browser reconnecting:
await _stream!.DisposeAsync();

Drop the server (or your network) while the stream is open and the browser reconnects by itself, sending the last id it saw as a Last-Event-ID header. The demo endpoint reads that header and carries on counting rather than starting from one - which is the whole point of ids. GetState reports Connecting during the gap, which is a normal mid-stream state rather than a failure.

var state = await _stream!.GetState();
// EventSourceState.Connecting - dropped, browser is retrying
// EventSourceState.Open       - delivering
// EventSourceState.Closed     - finished for good, no retry