SSE Frontend Implementation

[calebbourg]

Description

describe the intent of your changes here

GitHub Issue: [Closes|Fixes|Resolves] #your GitHub issue number here

Changes

• ...
• ...
• ...

Screenshots / Videos Showing UI Changes (if applicable)

Testing Strategy

describe how you or someone else can test and verify the changes

Concerns

describe any concerns that might be worth mentioning or discussing

[jhodapp]

This is looking great. We came up with one suggestion yesterday to handle the following event scenarios:

• To have an event that's just a signal for the client to do something (e.g. simple action like force logout)
• To have an event that the client just consumes the payload passively (e.g. simple event with a text message like a notification)
• To have an event that the client uses to update a component that display an Entity type via the payload (e.g. a specific action was added to the list of actions, or a specific action was updated)

I think I got these right, but my memory was a little fuzzy. Hope your written notes from our sync call yesterday captured it and can more accurately reflect what we discussed.

And here are some more general things to consider about the design and as you implement with Claude:

Connection State During Auth Transitions

useEffect(() => {
if (!isLoggedIn) {
eventSourceRef.current?.close();
// ...
return;
}
// Create new connection...
}, [isLoggedIn, ...]);

Circular Import Risk

Looking at the imports:

use-sse-connection.ts
→ imports useSseConnectionStore from sse-provider.tsx

sse-provider.tsx
→ imports useSseConnection from use-sse-connection.ts

This is a circular dependency. It may work due to how the exports are structured, but:

• Could cause issues with hot module reloading
• Could cause issues with tree-shaking
• Makes the code harder to reason about

Possible fix: Extract useSseConnectionStore and context to a separate file (sse-connection-context.ts).

Scenarios to consider:

Scenario	What happens?
Page load while logged in	Connection created immediately? Or after hydration?
Login completes	Does isLoggedIn update synchronously trigger connection?
Token refresh	Does auth state flicker? Could cause disconnect/reconnect?
Logout while reconnecting	Race between cleanup and reconnection?

The logoutCleanupRegistry integration helps, but the interplay with React's effect timing deserves attention.

Missing Reconnection State

Phase 2 mentions Reconnecting as a state:

States: Disconnected, Connecting, Connected, Reconnecting, Error

But the actual enum only has four states:

export enum SseConnectionState {
  Disconnected = "Disconnected",
  Connecting = "Connecting",
  Connected = "Connected",
  Error = "Error",  // No Reconnecting!
}

Native EventSource auto-reconnects silently. How do you know if you're in a reconnection vs. first connection? The onerror fires, but then... does onopen fire again on successful reconnect?

If you want accurate UI states, this needs clarification.

[jhodapp]

Provider Dependency Chain

The nesting order in providers.tsx:

<AuthStoreProvider>           // 1. Auth state
  ...
    <SWRConfig>               // 2. SWR cache
      <SseProvider>           // 3. SSE (needs both auth AND SWR)
        {children}
      </SseProvider>
    </SWRConfig>
  ...
</AuthStoreProvider>

The concern: SseProvider calls useAuthStore() and useSWRConfig().

• Does useAuthStore work correctly when called from inside SseProvider during initial render?
• What's the initialization sequence when the app first loads?

It's worth tracing through the mount sequence mentally or with a quick prototype.

[calebbourg]

I added a note on this to the plan in b6c963a

I worked with Claude for a while on it and decided that I didn't want to touch auth logic as part of this effort as I was afraid that it would lead to regression and potentially just a headache of scope creep. Let me know what you think

[calebbourg]

@jhodapp I updated the plan to remove the circular dependency and add a reconnection state bc8cb85