Support for custom message types & SSE events with non-TanStack backend

[nirtamir2]

I’m using tanstack/ai on the frontend, but my backend is written in Python and does not use TanStack AI internally.

Instead, I map my backend responses to match the expected API format.

Use case

I want to send custom message types from the backend to the frontend, for example:
• Render a custom UI component in chat (not just text/tool)
• Trigger client-side events (e.g. image generation, canvas updates, etc.)

Questions
1. What is the recommended way to send custom message types through the TanStack AI protocol?
2. Can the client handle arbitrary message types, or is it restricted to known types?
3. Is there a documented way to extend the protocol?

SSE simulation

Since my backend is not TanStack-based, I also want to simulate the expected SSE stream.

Is there:
• documentation or examples of the exact SSE format expected?
• a reference implementation of the event stream?

For example:
• What events are required?
• What order should they be sent in?
• Which fields are mandatory?

In the meanwhile I still have https://github.com/nirtamir2/tanstack-ai-issues-reproduction/ to reproduce stuff, I tries to simulate the SSE - but I don't know what is "correct"

[barry166]

I would not extend the core message-part protocol for this. Keep the backend stream mapped to the known TanStack/AG-UI events for normal chat output, tool calls, tool results, run start/end, etc., then put app-specific UI signals on the custom-event side channel.

On the client, handle those with onCustomEvent:

const chat = useChat({
  connection: fetchServerSentEvents('/api/chat'),
  onCustomEvent: (eventType, data, context) => {
    // e.g. image progress, canvas updates, VM logs, etc.
    // context.toolCallId lets you attach the event to a specific tool call
  },
})

For a Python backend, the safest shape is to write a small adapter layer: translate your backend's SSE into the standard event stream that fetchServerSentEvents / ConnectionAdapter expects, and emit custom events only for extra UI/progress data. Arbitrary message part.type values are not the stable extension point; render custom UI from known parts plus the custom events or your own app state keyed by message/tool-call id.