A chat front end in the browser

Model output is untrusted input

Treat a model's reply the way you treat a form field from a stranger. People can steer a model into writing anything, directly or by planting instructions in a document it reads; that's prompt injection. If your page then parses the reply as HTML, their markup runs with your page's access: it can read what's on screen, send requests as the signed-in user, or swap your page for a fake login.

The rule is short: put untrusted text in textContent, never innerHTML. When you want formatting, such as Markdown with bold text and lists, convert it with a renderer that escapes HTML and then clean the result with a sanitizer library built for it, like DOMPurify. Writing your own filter with a regular expression is how most cross-site scripting bugs are born.

The same goes beyond chat: product names, file names and user profiles all came from outside your code. The practice page warns you under the output when your code has built something that would run.

document.body.innerHTML = '<div id="log"></div>';

function showReply(text) {
  const bubble = document.createElement("div");
  bubble.className = "msg assistant";
  bubble.innerHTML = text;
  document.getElementById("log").append(bubble);
  return bubble;
}

showReply("The Ridge tent sleeps two.");
showReply('Here it is: <img src=x onerror="alert(document.cookie)">');

Streaming a reply

Asked with stream: true, the practice chat service sends its reply as server-sent events: lines like data: {"delta":"The "} each followed by a blank line, and a final data: [DONE]. res.body is a stream of bytes; a reader hands them over in chunks as they arrive, and a TextDecoder turns bytes into text.

const res = await fetch("https://chat.trailhead.test/v1/chat", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({ messages: [{ role: "user", content: "Tell me about the tent" }], stream: true }),
});
const reader = res.body.getReader();
const decoder = new TextDecoder();
let chunks = 0;
let raw = "";
for (;;) {
  const { value, done } = await reader.read();
  if (done) break;
  chunks += 1;
  raw += decoder.decode(value, { stream: true });
}
console.log(chunks, "chunks");
console.log(raw.split("\n\n").slice(0, 2));

A chunk is whatever the network delivered, not one event. On a real connection one chunk can hold three events, or half of one, so parsers keep a buffer: add each chunk, cut off every complete event (they end in a blank line), and keep the unfinished tail for next time.

const chunks = ['data: {"delta":"Hel', 'lo"}\n\ndata: [DONE]\n\n'];
let buffer = "";
const deltas = [];
for (const chunk of chunks) {
  buffer += chunk;
  const events = buffer.split("\n\n");
  buffer = events.pop();
  for (const e of events) if (e !== "data: [DONE]") deltas.push(JSON.parse(e.slice(6)).delta);
}
console.log(deltas, JSON.stringify(buffer));

function takeEvents(buffer) {
  // split off complete events, keep the tail, collect the deltas
  return { deltas: [], rest: buffer, done: false };
}

console.log(takeEvents('data: {"delta":"Hi "}\n\ndata: {"delta":"there"}\n\ndata: {"del'));

Stop, and staying usable while it streams

A reply can run for many seconds, so give people a way out. Create an AbortController for each request, pass its signal to fetch, and call abort() from the Stop button; the reader then rejects with an AbortError, which your code catches and treats as a normal ending, not a failure.

While a reply streams, disable Send so a second question can't start a second stream into the same bubble, and re-enable it in a finally block so an error can't leave the page stuck. Two small touches help everyone: give the message list role="log" and aria-live="polite" so screen readers announce new messages, and move focus back to the text box when a reply ends.

Keep the conversation in an array of { role, content } messages and send all of it with each request, because the model remembers nothing between calls. The page shows that array; it isn't the source of it, so never rebuild the history by reading text back out of the bubbles.

When the request fails

Three things go wrong in practice, and each deserves a message on the page rather than a silent line in the console. The service answers with an error status: a 429 or 503 means it's busy, so say so, offer a Retry button that sends the same history again, and wait a little before retrying on your own. The network drops: fetch rejects with a TypeError, so say the connection was lost and leave the question in the text box, so nothing has to be typed again. Or the stream stops halfway: keep the words that arrived, add a short note that the reply is incomplete, and keep the history matching what the person saw.

Put these messages in an element with role="alert", so screen readers announce them, and style them so they can't be mistaken for the assistant. An error that looks like the model talking will be believed, and quoted back to you as the product's answer.