Late, duplicate, unknown and broken messages
The same applyEvent runs in your project. A message older than what a station already has is ignored, a count is clamped to the docks, and nothing throws.
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
{"id":"S01","bikes":8,"seq":101} -> applied
{"id":"S01","bikes":12,"seq":99} -> late
{"id":"S01","bikes":8,"seq":101} -> late
{"id":"S02","bikes":30,"seq":102} -> applied
{"id":"S77","bikes":3,"seq":103} -> unknown
not json at all -> bad (SyntaxError)
null -> bad
{"id":"S02","bikes":"4","seq":104} -> bad
Quay: 8 of 20 | Mill: 10 of 10
emptiest first: Quay 40%, Mill 100%
last 5 readings: [ 4, 8, 9, 7, 6 ]