Hasta ahora tus datos llegaban porque TÚ los pedías: un fetch, un useQuery. Pero un chat, una
notificación, "Luis está escribiendo…", el precio de una acción que cambia solo —eso no puedes pedirlo
cada vez: tiene que LLEGARTE cuando pasa—. Ese es el salto del tiempo real: del modelo "pregunta y
espera respuesta" (request/response) al modelo "el servidor te EMPUJA los datos cuando ocurren"
(push). Hoy entiendes por qué HTTP no basta, qué es un WebSocket, y sientes el "push" en vivo.
El teléfono que queda descolgado
Pull vs push: el problema del polling
El "push" en vivo
Este playground simula un servidor que te EMPUJA eventos (aquí con un temporizador que hace de
servidor). Conéctate y observa cómo los mensajes LLEGAN solos, sin que pidas nada:
Al conectar, los eventos aparecen SOLOS cada 1.5s —tú no haces fetch, ellos te LLEGAN—. Eso es el
push. Fíjate en dos cosas que se repetirán todo el módulo: la conexión se ABRE en un efecto y se CIERRA
en el cleanup (una conexión abierta es un recurso que hay que limpiar, como los timers del módulo 3), y
los mensajes entrantes actualizan el estado que React repinta. Aquí el "servidor" es un setInterval
simulado; en una app real sería un WebSocket hablando con un servidor de verdad.
¿Cuál es la diferencia entre el modelo pull (HTTP normal) y push (WebSocket) para datos en tiempo real?
Mini-reto
Experimenta con el push: 1) agrega un segundo botón "Pausar/Reanudar" que detenga el feed sin
desconectar (una bandera que el alRecibir respete); 2) muestra un contador de "mensajes recibidos"
total; 3) en un comentario, explica por qué el return desconectar del efecto es imprescindible (pista:
¿qué pasaría con el setInterval si el componente se desmonta sin limpiarlo?). Siente que una conexión
es un recurso vivo que hay que cerrar.
Qué sigue
Ya sentiste el push. La próxima lección trae el WebSocket NATIVO del navegador —la API WebSocket
real: new WebSocket(url), onmessage, send, onclose— para que veas el mecanismo crudo antes de
usar Socket.io, la librería que lo hace práctico.