Part V — The Craft · Lesson 10.13
Real-Time Updates
In one lineMerge live events into rendered lists without losing the user's place or their scroll position.
Where you've seen itA live order screen updating itself, and a feed that politely says "3 new posts" instead of jumping.
Diagram
THE PIPELINE
transport (2.4 / 2.5)
│ {type:'post.updated', id:'p7', data:{…}, seq: 812}
▼
┌──────────────┐ dedupe by seq/id · ignore stale (seq < last)
│ NORMALISE │ reshape to your entity form (6.6)
└──────┬───────┘
▼
┌──────────────┐ update → merge into byId
│ REDUCER │ create → add to byId, decide list placement
└──────┬───────┘ delete → tombstone, then remove
▼
┌──────────────┐ only components selecting that entity
│ UI │ re-render (10.5)
└──────────────┘INSERTS: NEVER YANK THE VIEWPORT
user at top of list user scrolled down
┌────────────────┐ ┌────────────────┐
│ [3 new posts ▲]│ ← banner │ item 40 │
│ item 1 │ │ item 41 │ ← new items appended
│ item 2 │ │ item 42 │ ABOVE would push
└────────────────┘ └────────────────┘ content down
insert on click buffer them; keep scroll anchored
Chat is the exception: pin to bottom ONLY if already at bottom.LOCAL EDIT vs SERVER EVENT — the conflict everyone hits
user typing in the row server event arrives for that row
│ │
└──────────────┬───────────────┘
▼
is the field dirty (locally edited)?
┌─────────────┴─────────────┐
yes no
│ │
keep local value apply server value
+ mark "updated elsewhere"How it works
- Give every event a sequence number or version, and drop anything older than what you've applied — out-of-order delivery is normal.
- Reduce into a normalized store (6.6) so one event updates every view showing that entity.
- Buffer inserts behind a "N new items" affordance unless the user is at the top; never shift content under a reading user.
- Protect local edits. Track dirty fields and don't let a server event overwrite something the user is typing.
- Reconcile on reconnect: after any gap, fetch the delta since your last sequence number rather than trusting the stream (2.4).
function reducer(state, event) {
if (event.seq <= state.lastSeq) return state; // stale
switch (event.type) {
case 'post.updated':
return { ...state, lastSeq: event.seq,
byId: { ...state.byId, [event.id]: merge(state.byId[event.id], event.data) } };
case 'post.created':
return { ...state, lastSeq: event.seq, pending: [event.id, ...state.pending] };
default:
return { ...state, lastSeq: event.seq };
}
}Trade-offs
| Choice | Consequence |
|---|---|
| Apply inserts immediately | Content jumps under the user |
| Buffer with a banner | Slightly stale, always comfortable |
| Full refetch on event | Simple, wasteful, loses scroll |
| Patch by id | Efficient, needs normalization |
Throttle the UI, not the data. At high event rates, batch state updates into one render per animation frame; the network can handle 200 events per second, React re-rendering 200 times cannot.
Interview angle
"Live updates arrive while the user is scrolled into the feed. What do you do?"
- Buffer inserts behind a "N new posts" banner and keep scroll anchored; only auto-insert when the user is at the top.
- Patch entities by id in a normalized store so unrelated rows don't re-render.
- Handle sequence numbers, reconnect deltas, and dirty local fields — those three are what separate a real implementation from a demo.
Recap
- Sequence numbers make out-of-order and duplicate events harmless.
- Buffer inserts; never move content under someone who's reading.
- Batch renders per frame — the UI is the bottleneck, not the socket.