El canal de vuelta
El core también habla sin que le pregunten. Qué problema resuelve un evento que un comando no puede resolver, las tres familias de cosas que llegan por aquí, y por qué un frontend que sondea casi siempre es un evento que falta.
Lo que un comando no puede
Un comando siempre lo empieza el frontend. Eso deja fuera todo lo que ocurre cuando el frontend no está preguntando:
Las tres familias
El sondeo es un evento que falta
Es la señal más fiable de este nivel, y aparece en casi todos los proyectos:
// Si ves esto, falta un evento.setInterval(async () => { const estado = await commands.estadoSincronizacion(); pintar(estado);}, 1000);Ese código hace sesenta cruces por minuto, la inmensa mayoría para descubrir que nada ha cambiado, y aun así llega tarde: entre dos consultas hay hasta un segundo de retraso.
La versión correcta invierte la dirección —el nivel 13.4 ya lo adelantaba—: el core avisa cuando algo pasa, y el frontend no pregunta nunca. Un cruce por cambio real, y sin retraso.
La única situación donde el sondeo se defiende es cuando el dato cambia constantemente y solo quieres una muestra cada tanto —un uso de CPU, por ejemplo—. Y aun así, casi siempre es mejor que el core emita a la frecuencia que quieras y el frontend no decida nada.
Dónde encaja en el modelo
Los eventos no rompen nada de lo aprendido en el nivel 4.1. La autoridad sigue siendo del core:
- El core decide qué se emite y cuándo. El frontend no puede pedir que se le informe de algo que el core no haya decidido emitir.
- El evento es un aviso, no una orden. Lo que el frontend haga al recibirlo es cosa suya.
- Y necesita permiso, igual que todo lo demás: escuchar eventos es una capacidad que la capability concede o no. Fase V.
Lo que sí introducen es una asimetría nueva: un evento no tiene respuesta. Se emite y ya está; si nadie escucha, no pasa nada y nadie se entera. Eso es una propiedad útil —el core no depende de que haya una ventana abierta— y una fuente de confusión cuando algo no llega y no hay ningún error que mirar.