Los tipos compartidos
Que el frontend y el core no se contradigan: generar los tipos de TypeScript desde Rust, qué garantiza eso y qué sigue sin garantizar.
El problema
Sin tipos generados, el contrato entre las dos mitades solo existe en la cabeza de quien lo escribió:
Y el fallo silencioso es especialmente malo aquí, porque cruzar el puente convierte una estructura de Rust en un objeto sin tipo: nada comprueba nada al llegar.
Qué garantiza
Los eventos, que suelen quedarse fuera
El hueco más común: los comandos se tipan bien y los eventos del nivel 19 a menudo no, con lo que el nombre del evento y la forma de su carga vuelven a ser un contrato informal.
Dos formas de cubrirlo:
- Un enumerado de eventos en Rust con su carga, y un tipo generado a partir de él. Si tu herramienta lo soporta, es lo correcto.
- O como mínimo, constantes compartidas para los nombres. Un evento emitido como
"proyecto-actualizado"y escuchado como"proyecto_actualizado"es un fallo silencioso clásico, y una constante lo impide.
Los nombres de evento son el punto más frágil de toda la comunicación entre las dos mitades, porque son cadenas en los dos lados y nada las relaciona.
Integrarlo sin fricción
Lo que hace que se use o se abandone:
- Que se genere solo, en la compilación del core, no con una orden que hay que recordar.
- Que el fichero generado esté en el repositorio o no según tu criterio, pero de forma consistente: lo peor es que a veces esté y a veces no.
- Y que la comprobación de tipos del frontend forme parte de tu verificación, o el tipo generado no sirve de nada: si nadie comprueba el frontend, un tipo cambiado no rompe nada visible.
El tercero es el que más se olvida: generar tipos y no ejecutar la comprobación es tener la red y no usarla.