Cuando la respuesta es un flujo
Una promesa se resuelve una vez, y hay operaciones cuyo resultado son mil cosas. Las tres formas de resolverlo, por qué el canal gana a los eventos para esto, y qué problema resuelve que los otros dos no.
Las tres formas
El problema de correlación
Es la razón de fondo por la que el canal existe, y merece verlo con un ejemplo.
Con eventos, dos operaciones simultáneas producen esto:
importar A ──▶ evento "import-progreso" { hechos: 10 }importar B ──▶ evento "import-progreso" { hechos: 3 } evento "import-progreso" { hechos: 11 } ← ¿de cuál?La salida habitual es meter un identificador en cada aviso y que cada listener filtre por el suyo. Funciona, y significa que has reimplementado a mano lo que un canal te da: un conducto que pertenece a una llamada concreta.
Con un canal, cada llamada tiene el suyo y no hay nada que separar:
importar A ──▶ su canal ──▶ { hechos: 10 }, { hechos: 11 }, … importar B ──▶ su canal ──▶ { hechos: 3 }, …Y las otras tres ventajas
No hay nombre global. Un evento es una cadena compartida por toda la aplicación, con el riesgo de colisión del nivel 20.2. Un canal no tiene nombre: es un objeto que se pasa.
No hay listener que desregistrar. El canal vive lo que dura la llamada. La fuga del nivel 20.4 no puede ocurrir.
Es más directo. Un evento pasa por el enrutado de destinos —a quién le toca esto— y un canal no: va de la llamada a quien la hizo. En un flujo de miles de mensajes, la diferencia se nota.
Cuándo sigue siendo mejor un evento
El canal no sustituye a los eventos, y el criterio es el mismo del nivel 20.5, tercera pregunta:
La prueba rápida: ¿tiene sentido que una ventana que se abre a mitad vea el progreso? Si sí, evento. Si no, canal.