This checks whether you can build a production streaming UI state machine: append partial output safely, preserve final message correctness, support cancellation, and recover from mid-stream failures.
Use this JavaScript interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.
How should a front-end handle streaming data from an AI model?Frontend interview answer
This JavaScript interview question tests whether you can explain AI streaming in frontend: partial output, cancellation, and failure handling, connect it to production trade-offs, and handle common follow-up questions.
- AI streaming in frontend: partial output, cancellation, and failure handling explanation without falling back to memorized docs wording
- Real Time and Streams reasoning, edge cases, and production failure modes
- How you would answer the most likely JavaScript interview follow-up
The Core Idea
Treat AI streaming as a production UI state machine, not just a transport detail. You open a stream (SSE, WebSocket, or fetch + ReadableStream), append partial output as chunks arrive, keep partial and final message state consistent, and stop cleanly when the user cancels or the stream fails.
Step | What happens | Why it matters |
|---|---|---|
Open stream | Connect via SSE/WebSocket or fetch stream | Start receiving tokens immediately |
Append chunks | Update UI incrementally as data arrives | Low latency UX |
Handle errors | Show retry/state on disconnect | Resilience on flaky networks |
Cancel/stop | AbortController or close socket | User can stop generation |
const controller = new AbortController();
const res = await fetch('/api/stream', { signal: controller.signal });
const reader = res.body.getReader();
const decoder = new TextDecoder();
let text = '';
while (true) {
const { done, value } = await reader.read();
if (done) break;
text += decoder.decode(value, { stream: true });
render(text); // append to UI
}
// controller.abort() to cancel
Production scenario
Suppose a chat answer streams for 20 seconds and the user switches prompts halfway through. If you do not model streaming, completed, cancelled, and failed states explicitly, you can show mixed output, mark a partial answer as final, or append late tokens into the wrong conversation. Good implementations treat partial text, final text, retry UI, and cancellation as separate states.
Open a stream, append chunks to the UI, and handle cancel + errors gracefully. The UX should feel responsive even before the full response finishes, but the real production requirement is keeping partial and final output correct.
Use this as one explanation rep, then continue with the JavaScript interview questions cluster or a guided prep path.