# Design the Frontend for an AI Chat Application Design the frontend architecture for a conversational AI application. Cover streaming responses, conversation state, interruption and retry behavior, long histories, failure recovery, accessibility, and the boundary between browser and backend responsibilities. ### Constraints & Assumptions - A user may have many conversations and thousands of messages in one history. - Assistant output arrives incrementally and may include structured content such as code blocks. - A user can stop generation, retry a response, edit a prior message, or leave and return. - Authentication, model execution, and durable authorization decisions remain on the server. - Connections can disconnect, responses can arrive late, and a request can be retried. ### Clarifying Questions to Ask - Which message types and attachments must the client render? - Does editing a prior message create a branch or overwrite later history? - What delivery guarantees and resume support does the streaming API provide? - Must drafts and partially streamed answers survive reloads? - What latency, browser, mobile, and accessibility targets apply? ### Hints - Give messages and generation attempts stable identifiers. - Separate durable conversation state from transient transport state. - Treat stop, retry, reconnect, and out-of-order events as state-machine transitions. ### What a Strong Answer Covers - Component and state boundaries for conversation navigation, message rendering, composer state, and generation controls. - A normalized message model with stable IDs, parent or branch relationships, attempt status, and idempotency keys. - Streaming transport choice, incremental parsing, cancellation, reconnect, deduplication, and late-event rejection. - Optimistic user messages with explicit pending, failed, retrying, stopped, and completed states. - History pagination or virtualization, code-block performance, draft persistence, and cache invalidation. - Accessible live updates, keyboard navigation, focus management, reduced motion, security boundaries, and observability. ### Follow-up Questions 1. How would the client resume a stream after a brief disconnect without duplicating tokens? 2. What state changes when a user edits an earlier message and creates a new branch? 3. How would you keep a rapidly growing code block from causing excessive rendering work? 4. Which data may be cached locally, and how would logout or account switching clear it safely?