A burst of 500 messages, one redraw
500 messages, two draws. applyEvent runs for every message, draw() only when the timer says so. Late messages are ignored only when that station already has something newer.
Live data raises four questions: how it arrives, in what order, how often to draw it, and what to do when nobody is looking or it stops. Apply messages at once, draw on a timer, ignore late ones, and clean up when you leave.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write throttle(fn, ms) that calls fn at most once per ms, using the newest call's arguments. Where would the dashboard use it?
Add a rolling window of the last 60 bikes-docked readings per station to the state. What does the memory cost for 25 stations?
Explain it without notes
Compare polling, SSE and WebSocket for a dashboard that only displays data.
Why keep a sequence number and ignore older messages?
Why apply messages immediately but draw on a timer?
What should happen while the tab is hidden, and when it comes back?
Preview
Console
Nothing logged yet.Expected console output
stations in the snapshot: 25 | draws so far: 1
after the burst: applied 457 | late ignored 43 | draws 1
after waiting: draws 2
rows drawn: 5
title: 9 stations are below 40% full