Eye Training · Events, Listeners and Sockets

Every on asks four questions: when is it removed, how many times is it added, what if it fires twice at once, and what happens across a reconnect?

Part 2 · Surface 14. Bug counts are hidden and some snippets are clean. See Start Here for how to use these drills.

The snippets use the browser WebSocket, Node's EventEmitter, and Socket.IO (socket.on, socket.emit, io.to(room)). The habits are the same for all three.

J · The basics

M · Three years in, these should jump out

S · Where seniors stand out

What your eye checks

Whenever you see on, addEventListener, onmessage or once, ask:

1. Where is it removed? Find the matching off / removeEventListener / abort(). If there isn't one, what ends its life?
2. How many times does this line run? Inside a render, a connect handler, a function called per room or per request, it adds a listener every time.
3. Is off given the same function object? Inline arrows and .bind() create new ones.
4. Can it fire before the listener exists, or before the socket is open?
5. Who handles 'error'? In Node, an emitted 'error' with no listener throws.
6. What if two events are handled at once? Async listeners run concurrently; read-modify-write inside them races.
7. What happens across a reconnect? Re-subscribe (in connect), don't re-register listeners, resume from the last seen id, and back off with jitter.
8. Can events arrive twice or out of order? Make handlers idempotent and compare versions or sequence numbers.
9. Server side: who checked that this client may join or send to this room? Room ids from the client are untrusted input.
10. What does the connection own? Timers, subscriptions and map entries started per connection must be cleaned up on disconnect.

Tells

Go deeper

• Cancellation and Cleanup: Part 6, cleaning up what you started
• Race Conditions: stale responses and out-of-order events
• Casebook V: React and React Native: the same listener bugs inside effects
• Previous surface: Timers · Next: Streams and streaming data