Cuándo un evento y cuándo un comando

Las tres preguntas

Los dos antipatrones

Demasiados eventos. El síntoma es una aplicación donde el estado se actualiza y no se puede seguir por qué. Un componente cambia porque alguien emitió algo en algún sitio, y para averiguar cuál hay que buscar el nombre del evento por todo el proyecto. Con veinte eventos y tres emisores por evento, seguir un flujo se vuelve arqueología.

La causa suele ser usar eventos como sustituto de la comunicación normal: en vez de que un comando devuelva el resultado, emite un evento y quien quiera se entera. Es cómodo de escribir y produce un sistema donde nada tiene un emisor evidente.

Demasiados comandos. El síntoma es el sondeo del nivel 20.1: el frontend pregunta cada segundo si algo cambió, porque el core no tiene forma de avisar. Sesenta cruces por minuto y retraso garantizado.

La causa suele ser no querer añadir un mecanismo nuevo: con comandos ya funciona, así que se estira.

La asimetría entre los dos: el exceso de comandos cuesta rendimiento, que se mide y se arregla; el exceso de eventos cuesta trazabilidad, que no se mide y se paga en cada sesión de depuración. Por eso la regla de dedo cuando dudas es comando: deja rastro, tiene un llamante identificable, y devuelve algo que se puede seguir.

Los casos frecuentes

Y una regla de higiene

Si decides usar eventos, que su emisión esté acotada: un evento se emite desde uno o dos sitios, no desde ocho. La forma práctica de conseguirlo es que los eventos los emita la capa que posee ese dominio y no cualquiera que pase por ahí:

// mal: cinco sitios emiten proyecto-cambiado// bien: solo el módulo de proyectos lo emite, y lo hace en una funciónpub fn notificar_cambio(app: &AppHandle, p: &Proyecto) -> tauri::Result<()> {    app.emit(eventos::PROYECTO_CAMBIADO, &ProyectoResumen::de(p))}

Con eso, buscar quién emite un evento es buscar una función, y la trazabilidad vuelve.