Expose an isHydrating state from useChat

[Visualizeit]

Problem

When using server-authoritative persistence:

const chat = useChat({
  connection: fetchServerSentEvents('/api/chat'),
  persistence: true,
  threadId,
})

useChat hydrates the conversation asynchronously on mount.

While hydration is pending, the observable state is currently indistinguishable from an empty, ready conversation:

chat.status === 'ready'
chat.isLoading === false
chat.messages.length === 0

There is no public hydration state or lifecycle callback.

This makes it difficult to distinguish between:

• Hydration still pending
• A legitimately empty conversation
• Hydration completed
• Hydration failed
• Hydration superseded by a new send

Applications may consequently enable sending before the server-authoritative transcript, pending interrupts, or active run has been restored.

Using messages.length === 0 is unreliable because an empty conversation is valid. Wrapping connection.hydrate() adds application glue and only observes the transport promise, not when ChatClient has finished applying the result.

Proposal

Expose isHydrating from ChatClient and framework hooks:

const {
  messages,
  isHydrating,
  isLoading,
  sessionGenerating,
  sendMessage,
} = useChat({
  connection,
  persistence: true,
  threadId,
})

Suggested semantics:

• true while initial asynchronous persistence hydration is running.
• false after the result has been applied.
• false when hydration fails or is superseded by a new send.
• Synchronous persistence adapters should be false on the first observable render.
• Keep it separate from isLoading, status, and sessionGenerating.
• Do not otherwise change current non-blocking hydration behavior.

This would let applications make their own UX decision:

const isResponding = isLoading || sessionGenerating

<SendButton disabled={isHydrating || isResponding} />

Why a separate state?

isLoading represents a request initiated or rejoined by the client.
sessionGenerating represents shared generation activity.
isHydrating would represent restoration of persisted client state.

These lifecycles are related but not equivalent.

Current behavior

The current implementation treats server hydration as private, best-effort, and non-blocking. A new send can supersede it. That behavior is reasonable, but applications need visibility into the lifecycle to implement reliable input and loading states.

Relevant documentation:

• Client persistence
• useChat API