Caso de estudio 09 / 17React Front-End
Flujo unificado de reconocimiento de alarmas para la sala de control
Una ruta de reconocimiento para cuatro puntos de entrada, con estados confirmados por el servidor y un conteo único: respuesta en 74 ms.
Stack
- TypeScript
- React
- Next.js
- CSS animations
- CesiumJS
- postMessage
- MongoDB
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Los operadores reconocen alarmas desde una tabla de alarmas o desde una baliza sobre la vista 3D principal; el reconocimiento es la forma de dejar constancia de que una alarma fue vista, así que la interfaz nunca debe ser ambigua.
Leer más
Rehíce el reconocimiento como una sola ruta compartida para los cuatro puntos de entrada y ambos tipos de sistema. Hoy un clic se confirma al instante, todos los conteos coinciden y la baliza queda sobre el mapa 3D.
6 conexiones· elige un componente para ver su recorrido
- Operador a Paso común de reconocer: hace clic en reconocer
- Paso común de reconocer a Fila de alarma: muestra enviando al instantemodificado
- Paso común de reconocer a API: lo envía, 1 recarga de lista
- API a Almacén de alarmas: guarda, nueva marca temporal
- API a Fila de alarma: aplica lista, ignora marca
- Paso común de reconocer a Servicio de mapas 3D: le pide recargar alarmas
02Resultados
- R01Cuanto más bajo, mejor
Peor espera entre el clic y el cambio en la fila
Antes 20,000 ms, después 74 ms, 270× menor. Cuanto más bajo, mejor.AntesDespués - R02Cuanto más bajo, mejor
Peticiones enviadas por reconocimiento
Antes 8, después 1, 8× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más alto, mejor
Pruebas del mapa con la baliza encima (de 8)
Antes 0, después 8, desde 0. Cuanto más alto, mejor.AntesDespués
Qué logró
- Respuesta tras un clic: sin cambios hasta 20 s → inmediata, con estados de envío, reconocida y fallida
- Conteo de alarmas: insignia y lista por separado → un conteo compartido, igual en 12 de 12 pruebas
Leer más
- Baliza sobre el mapa con los paneles ocultos: nunca encima → encima en 8 de 8 pruebas
- Manejo de fallas: solo en la consola del navegador → un aviso en la fila si la alarma sigue listada tras 30 s
- Peticiones por reconocimiento: 8 → 1
El desafío
El servidor nunca fue el cuello de botella. Guardaba cada reconocimiento y devolvía de inmediato la lista actualizada, pero el cliente descartaba esa respuesta porque su marca de tiempo coincidía con la anterior. La fila quedaba igual hasta 20 segundos y el botón volvía a su estado inicial como si la acción hubiera fallado.
Alrededor de ese defecto estaban los problemas de estructura: los errores solo llegaban a la consola del navegador, solo una fila podía estar en curso y cada reconocimiento volvía a pedir ocho tipos de datos.
Leer más
Sobre el mapa 3D, la baliza desaparecía al ocultar los paneles laterales, y su insignia y la lista de alarmas llevaban conteos separados. En un flujo de alarmas, cada uno de estos puntos erosiona la confianza del operador.
Qué aprendí
Antes de culpar al servidor, hay que verificar qué hace el cliente con una respuesta correcta. Un control de marca de tiempo la descartaba; una recarga que lo omite, más estados explícitos por fila, lo resolvió, y una fila aparece como reconocida solo cuando el servidor lo confirma.
Leer más
Los defectos de capas rara vez ceden ante un z-index mayor: un filtro de fondo atrapaba la baliza bajo el mapa, así que ahora se renderiza a través de la capa de superposición del propio mapa. También diseñé una baliza más sobria; tras la revisión se descartó, y rehíce la original solo con transform y opacity.
Stack
- TypeScript
- React
- Next.js
- CSS animations
- CesiumJS
- postMessage
- MongoDB
Habilidades
- Diseño de interacción
- Gestión de estado
- UI en tiempo real
- Rendimiento de renderizado
- Análisis de causa raíz
