FluxyChatCore SDK
Connection state
Lifecycle, reconnect backoff, transport fallback, degraded-http.
FluxyChatClient and useChat expose structured connection state, not a boolean.
Status values
| Status | Meaning |
|---|---|
connecting | First WebSocket handshake |
connected | Live on WebSocket |
reconnecting | Socket dropped, backoff retry in progress |
degraded-http | Socket down, HTTP publish still works (canPublishViaHttp) |
degraded | Unhealthy, not the HTTP fallback path |
disconnected | Not connected (manual disconnect or fatal error) |
Legacy sse and polling statuses normalize to degraded-http. connectionState.transport still tells you sse vs polling.
Transport fallback
When WebSocket reconnect attempts are exhausted, the SDK degrades automatically:
- WebSocket: primary (
/ws/room/:roomId?token=…) - SSE:
GET /rooms/:id/streamwith member JWT - Polling:
GET /api/messagesevery ~4s
When WebSocket recovers, SSE/polling stops.
const { connectionState } = useChat({ roomId, client });
if (connectionState.status === "reconnecting" && connectionState.nextRetryAt) {
const seconds = Math.max(
0,
Math.ceil((new Date(connectionState.nextRetryAt).getTime() - Date.now()) / 1000),
);
return <span>Reconnecting in {seconds}s</span>;
}
if (connectionState.status === "degraded-http" && connectionState.canPublishViaHttp) {
return <span>Live socket down. Sends still go over HTTP.</span>;
}Client events
client.on("connectionStateChange", (state) => {
console.log(state.status, state.transport);
});
await client.connect();
await client.disconnect();JWT refresh: client.setToken(next) (alias updateToken). Reconnect rooms if sub changed.
If the live socket is blocked (corporate proxy, strict CSP), the UI should read connectionState.status === "degraded-http" and canPublishViaHttp. Sends still go over HTTP. This is not a second product; it is the same room.