Consuming WebSocket Data in a React App

The plain-language idea

An earlier lesson in this app covers what a WebSocket mechanically is — a persistent, full-duplex connection that starts as HTTP and upgrades. This lesson is about the part that actually breaks in real apps: wiring that connection correctly into a React component's lifecycle.

Three concrete things go wrong in practice, in order of how often they show up:

• The connection outlives the component. A WebSocket opened when a component mounts has to be closed when it unmounts. Forget the cleanup step and the socket keeps running after the component is gone — a real, common connection leak, not a theoretical one.
• A dropped connection needs to reconnect itself. A WebSocket does not recover from a network blip or a server restart on its own. Production code has to notice the close, wait, and try again — and retrying instantly, over and over, just hammers a server that's already struggling.
• Incoming messages need to land in current state, not stale state. A message handler that was attached once when the effect first ran can end up holding onto whatever props or state existed at that moment — a stale closure — instead of what's current by the time a message actually arrives.

See it in a real thing: a live chat feed

function useChatFeed(roomId: string) {
  const [messages, setMessages] = useState<ChatMessage[]>([]);
  const [status, setStatus] = useState<"connecting" | "open" | "reconnecting">("connecting");

  useEffect(() => {
    let socket: WebSocket;
    let reconnectTimer: ReturnType<typeof setTimeout>;
    let reconnectDelay = 1000;
    let unmounted = false;

    function connect() {
      socket = new WebSocket(`wss://api.example.com/rooms/${roomId}`);

      socket.onopen = () => {
        setStatus("open");
        reconnectDelay = 1000; // reset backoff after a successful connect
      };

      socket.onmessage = (event) => {
        const message: ChatMessage = JSON.parse(event.data);
        // Functional update reads the LATEST messages array, not whatever
        // array existed when this handler was first attached.
        setMessages((prev) => [...prev, message]);
      };

      socket.onclose = () => {
        if (unmounted) return;
        setStatus("reconnecting");
        reconnectTimer = setTimeout(connect, reconnectDelay);
        reconnectDelay = Math.min(reconnectDelay * 2, 30000);
      };
    }

    connect();

    return () => {
      unmounted = true;
      clearTimeout(reconnectTimer);
      socket.close();
    };
  }, [roomId]);

  return { messages, status };
}

The cleanup function is doing two jobs at once: it closes whatever socket is currently open, and it flips an unmounted flag so a reconnect attempt that was already scheduled doesn't fire and open a brand-new connection after the component is gone. Skip either half and you get a leak — either a socket nobody's listening to anymore, or a reconnect loop that keeps recreating one.

What people usually miss

Watch out

• "It reconnected" isn't the same as "it reconnected correctly." A reconnect that doesn't reset the backoff delay after a successful connection keeps growing the wait time forever, even once the network is fine again.
• useEffect's cleanup function is not optional cleanup — it's the only place a socket should close. Closing a socket from an unrelated event handler or a manual "disconnect" button click, instead of the effect's own return function, means the effect's own lifecycle and the socket's actual lifecycle drift apart.
• A stale closure bug doesn't crash — it just silently uses old data. A handler that reads a prop or piece of state directly (not through a functional updater or a ref) captures whatever that value was when the effect last ran, and keeps using it even after the real value changes, with no error to point at the bug.
• Hand-rolling this is a real, valid choice, but not the only one. Dedicated data-fetching and subscription libraries exist specifically because this connect/cleanup/reconnect/stale-closure shape is easy to get subtly wrong — reaching for one of them is often the more honest engineering call than reinventing it per component.

Why this matters in interviews

"How would you handle a live data feed in a React component?" is a real, common systems question, and naming the cleanup-on-unmount step, backoff on reconnect, and the stale-closure risk unprompted is what separates someone who's actually shipped this from someone who's only called new WebSocket() once in a demo.