Building a Chat UI

The plain-language idea

The state at the heart of any chat interface is an array of messages, each with a role ("user" or "assistant", sometimes "system") and content. Everything the UI does is really just operations on that array:

• Optimistic append — the moment a user sends a message, it goes into the array and renders immediately, before any response has come back. The UI doesn't wait for a round-trip to show what the user just typed.
• Streamed growth — as the assistant's response streams in token by token, you're not waiting for a complete message and appending it once. You append one new "in-progress" assistant message up front, then keep updating that same message's content as tokens arrive (this is the same streaming mechanism covered in the streaming lesson — a chat UI is one of its most common consumers).
• Streaming-to-complete transition — when the stream ends, that in-progress message needs to flip to a finished state: stop showing a typing indicator, re-enable the input, and treat the message as done (so, for example, a "regenerate" action knows there's a complete response to regenerate from).

See it in a real thing: the message array shape

type ChatMessage = {
  id: string;
  role: "user" | "assistant";
  content: string;
  status: "complete" | "streaming";
};

// Sending: append the user's message immediately, then start a streaming placeholder
function onSend(text: string, messages: ChatMessage[]): ChatMessage[] {
  return [
    ...messages,
    { id: crypto.randomUUID(), role: "user", content: text, status: "complete" },
    { id: crypto.randomUUID(), role: "assistant", content: "", status: "streaming" },
  ];
}

// On each streamed token: append to the last message's content, don't replace the array
function onToken(token: string, messages: ChatMessage[]): ChatMessage[] {
  const last = messages[messages.length - 1];
  return [...messages.slice(0, -1), { ...last, content: last.content + token }];
}

This is the same shape this app's own AI call sites are built around: every request goes through lib/ai/chat/handler.ts's handleChat, which is the single entry point regardless of which UI surface (tutor, interview) is consuming the stream — the message-array-plus-streaming-append pattern above is what any UI built on top of it needs to implement.

What people usually miss

Watch out

• Auto-scroll has to respect a user who scrolled up. Naively scrolling to the bottom on every new token fights anyone reading earlier messages — the fix is to only auto-scroll when the user was already at (or near) the bottom before the new content arrived, and stop once they scroll away.
• The input needs to be disabled while a response is in flight, not just visually indicated as busy — otherwise a user can queue up a second message mid-stream and create a confusing, out-of-order state.
• A visible stop/cancel control is a real requirement, not a nice-to-have. Long-running generations need a way to cancel — both for UX (the user changed their mind) and for cost (an abandoned tab shouldn't keep streaming tokens nobody's reading).
• "Streaming" and "complete" are genuinely different states the UI has to render differently, not just a boolean loading flag — a streaming message might show a typing cursor and disable regenerate/copy actions that only make sense on a finished message.

Why this matters in interviews

"Design the state for a streaming chat interface" is a common practical/whiteboard question, and describing the message-array-plus-in-progress-message pattern, plus naming the scroll/cancel/disabled-input details unprompted, is what separates a candidate who's actually built one from someone describing it in the abstract.