Kit de dashboard para React: filtros, métricas y datos

Un kit de dashboard para React debe mantener cada métrica vinculada a los filtros que produjeron sus datos. Empieza por una pregunta analítica, muestra el alcance aplicado y diseña los estados de carga, vacío, datos anteriores y fallo antes de conectar toda la pantalla. Prueba los cambios rápidos de filtros con el mismo cuidado que el gráfico final. Usaremos un panel ficticio de soporte: sus cifras y criterios de aceptación son ejemplos propuestos, no resultados medidos de un producto.

Define la métrica y su alcance

Empieza por una pregunta que una persona pueda responder: «¿Cuántas solicitudes resolvió el equipo de Europa esta semana?». El ejemplo necesita un equipo, un intervalo, una definición de resuelta y una hora de actualización. Escribe estos elementos junto a la especificación de la métrica antes de escoger los colores del gráfico. Una tarjeta titulada «Resueltas» con una cifra grande deja demasiada interpretación al lector, aunque su tipografía resulte convincente.

Prepara datos de prueba pequeños con dos equipos y dos periodos. Para Europa, utiliza 128 solicitudes resueltas en el primer intervalo y 96 en el siguiente. Asigna totales distintos al otro equipo e incluye un intervalo vacío. Estas cifras inventadas permiten detectar si el encabezado cambia mientras la tarjeta conserva el resultado anterior. El conjunto debe ser lo bastante sencillo como para comprobarlo a mano.

Considera cada resultado como un paquete de alcance, valores y metadatos de obtención. El alcance contiene los filtros enviados realmente; la hora indica cuándo se obtuvo ese resultado. Un porcentaje también necesita un periodo de comparación explícito y una política cuando el denominador sea cero. Decide si un guion significa no disponible, no aplicable o pendiente de cálculo: evita que el mismo símbolo comunique las tres situaciones.

Usa ese paquete como unidad de aceptación. Quien revise una captura debería identificar el equipo y periodo correspondientes a sus totales. Es el contrato de dashboard que proponemos, no una obligación de una biblioteca. Para elegir componentes en un flujo diferente, consulta la guía de aceptación de kits React con formularios y diálogos.

Separa filtros editados y filtros aplicados

Cuando existe un botón Aplicar, los controles pueden contener cambios que todavía no corresponden al resultado. Separa deliberadamente un borrador editable de filtros y una consulta aplicada. Así se pueden cambiar ambas fechas antes de solicitar el informe. Si no existe esa distinción, un encabezado puede sugerir que los valores aún incompletos ya describen el gráfico inferior.

React recomienda agrupar el estado relacionado y evitar contradicciones o duplicaciones. En esta pantalla, agrupa el equipo y el intervalo aplicados. Conserva el resultado con la identidad de su consulta. El borrador está justificado porque representa cambios sin enviar; otra copia de una etiqueta calculable suele sobrar. Deriva «Europa · 1–7 de octubre» de la consulta aceptada, en lugar de mantener un texto independiente que pueda quedarse desactualizado.

La transición propuesta es editar, aplicar, solicitar y aceptar. Al aplicar, valida el intervalo y crea una instantánea de la consulta. Un resultado solo reemplaza el paquete visible cuando pertenece a la petición vigente. Mientras actualizas, conserva el paquete anterior unido a su alcance original o sustitúyelo por una carga claramente identificada. No coloques la etiqueta del periodo nuevo sobre cifras antiguas sin explicar la diferencia.

Si tu producto actualiza al cambiar un control, documenta esa política y evita prometer una aplicación posterior innecesaria. Prueba el teclado, el restablecimiento de filtros y el cambio de equipo con ediciones pendientes. Decide si Restablecer cambia solo el borrador o solicita también el informe predeterminado. Incluye esa conducta en el contrato del componente para que quien lo implemente no tenga que deducirla del botón.

Evita que una respuesta antigua sustituya al informe

Cambiar filtros rápidamente revela un fallo que una previsualización estática no puede mostrar. La petición A solicita el primer periodo. Poco después, B solicita el siguiente. B termina antes. Si A reemplaza entonces las cifras visibles, el dashboard presenta una respuesta antigua bajo los controles más recientes.

La documentación de useEffect de React muestra cómo ignorar respuestas obsoletas mediante la limpieza y explica limitaciones de obtener datos directamente desde Effects. Emplea el mecanismo de carga adecuado para tu aplicación; si programas la obtención manual, define cómo pierde una respuesta antigua el permiso de actualizar la pantalla. Cancelar una solicitud puede ahorrar trabajo, pero también necesitas una regla explícita para aceptar el resultado visible.

En la prueba, retrasa A y deja que B termine inmediatamente. La tarjeta aceptada debe seguir mostrando 96 cuando A devuelva 128. Repite el caso haciendo que A falle después del éxito de B. Un error obsoleto tampoco debe sustituir un resultado vigente por un panel de fallo. Registra la identidad de las peticiones en el diagnóstico de desarrollo, sin añadir identificadores técnicos confusos a la interfaz de lectura.

Prueba también a salir de la ruta con una petición pendiente y regresar. Define qué datos de caché pueden aparecer, a qué alcance pertenecen y cuándo se actualizan. La guía de integración con App Router trata los límites del framework si trabajas en ese entorno. Aquí nos centramos en la integridad del resultado presentado, con independencia de la biblioteca de consultas elegida.

Distingue carga, cero y fallo

Dibuja los estados del informe antes de conectar datos reales. Una primera solicitud no tiene un resultado aceptado. Una respuesta vacía correcta sí tiene resultado, pero no registros coincidentes. Una actualización fallida puede conservar un resultado anterior. Representar todo mediante un gráfico en blanco impide decidir si conviene esperar, cambiar filtros o reintentar.

En el ejemplo, muestra «No hay solicitudes resueltas en este periodo» únicamente después de una respuesta vacía correcta. Ofrece cambiar el intervalo sin culpar a la persona. Durante la primera carga, reserva una región estable y describe la tarea. Si falla una actualización, conserva el resultado anterior solo con su alcance original y un aviso visible del fallo. El reintento debe solicitar la consulta aplicada en ese momento.

La guía de mensajes de estado de W3C aborda los avisos disponibles programáticamente sin recibir el foco. Emplea un mensaje conciso para comunicar una actualización o un fallo cuando corresponda. No conviertas cada elemento animado del gráfico en un anuncio. Comprueba qué se escucha con tecnología de asistencia: «Informe actualizado» resulta menos útil que un aviso breve que identifique también el alcance o resultado relevante.

Redacta la recuperación pensando en la siguiente decisión. «No se pudo actualizar Europa para el 8–14 de octubre; se muestra el 1–7 de octubre» aporta contexto útil en nuestro caso. «Algo ha fallado» deja ambiguas las cifras. No uses cero como valor temporal de carga: el cero afirma algo sobre los datos. Conserva los tratamientos de error, vacío y actualización como ejemplos identificados durante la revisión del kit.

Compón el ejemplo visual con EmviUI

La imagen de dashboard de EmviUI permite comentar la jerarquía: navegación, tarjetas resumen y un gráfico mayor comparten pantalla. Examínala como ejemplo de diseño y anota dónde colocarías el equipo aplicado, el intervalo y el aviso de actualización en tu producto. La imagen no demuestra una conexión de datos React funcionando.

El catálogo actual de componentes de EmviUI presenta componentes Figma, entre ellos inputs, celdas de tabla, gráficos y estados vacíos. Puedes usarlos como punto de partida visual para componer una pantalla analítica filtrada y sus estados complementarios. Diseño puede comparar la primera carga y la actualización fallida antes de que desarrollo conecte el modelo de resultados. Así las carencias de la interfaz propuesta se vuelven concretas.

En el proyecto React, comprueba por separado qué entrega el paquete de implementación elegido. Revisa su código, comportamiento accesible, integración de estilos y documentación. No deduzcas la coordinación de peticiones a partir de una captura de Figma ni supongas que un gráfico visual incluye tus definiciones de negocio. Asigna una responsabilidad al modelo de consulta y otra a la revisión del contrato de presentación; en un equipo pequeño puede asumir ambas la misma persona.

Prepara una hoja de handoff con la etiqueta de alcance, definición de la métrica, datos de prueba y cinco estados del informe. Añade la regla para aceptar resultados y la política de conservación de los anteriores. Vincula los componentes visuales con sus equivalentes implementados cuando se elijan. La guía sobre alcance de kits y sistemas de diseño ayuda a definir cómo se mantiene ese trabajo inicial en el producto.

Mantén legible la pregunta analítica en móvil

En una pantalla estrecha, conserva la pregunta antes que la distribución de escritorio. Coloca el alcance aplicado cerca de la métrica principal, permite que el resumen de filtros ocupe varias líneas y mantén próximo el aviso que explica el resultado. En nuestro caso, hay que distinguir Europa del otro equipo sin abrir una navegación oculta.

La guía de reflow de W3C describe la presentación a una anchura equivalente a 320 píxeles CSS, con excepciones para contenido que requiere distribución bidimensional. Prueba los controles y explicaciones circundantes a esa anchura incluso si una tabla necesita su propia región de desplazamiento horizontal. La etiqueta de un dashboard no debería desaparecer porque su gráfico sea ancho.

Ofrece una alternativa legible para los valores necesarios para responder a la tarea. Si utilizas una tabla, sigue la guía de tablas de WAI para los encabezados estructurales y su relación con las celdas. En nuestro ejemplo, un resumen pequeño de equipo y periodo suele ser más fácil de consultar que un tooltip denso. Es una recomendación de diseño, no la afirmación de que todos los gráficos deban sustituirse por la misma tabla.

Ejecuta la prueba estrecha con nombres de equipos largos y traducidos, texto ampliado y un aviso de actualización fallida. Confirma que el aviso no separa la etiqueta de alcance de la cifra a la que afecta. Mantén visible el foco al abrir y cerrar filtros. Revisa el orden de lectura de la página renderizada: mover tarjetas visualmente puede dejar la explicación en un lugar inesperado para quienes usan teclado o lector de pantalla.

Revisa un escenario completo del informe

Revisa el recorrido analítico mediante un guion breve. Carga Europa para el primer periodo, edita el siguiente sin aplicarlo, envíalo y cambia de equipo antes de que termine la petición. Compara el alcance y las cifras tras cada paso. Repite con una respuesta sin registros y una actualización fallida. Incluye un reintento correcto para revisar también la recuperación.

Comprueba los cálculos por separado de la coordinación de red. La guía de React sobre Effects innecesarios recomienda calcular directamente los datos derivados de renderizado cuando no hay sincronización externa. Si los datos de prueba ya están cargados y un subtotal es un cálculo sencillo, evita otra máquina de estados dedicada solo a sincronizarlo. Define cuándo un total filtrado representa todo el informe y cuándo corresponde únicamente a la página visible.

Establece condiciones observables: las ediciones sin enviar no cambian la etiqueta del resultado aceptado; las respuestas obsoletas no prevalecen; un vacío correcto se distingue del fallo; las cifras conservadas mantienen su alcance; y la vista estrecha sigue respondiendo a la pregunta analítica. Guarda los datos de prueba y resultados junto a la revisión del componente para repetir el ejercicio tras futuros cambios. Amplía las métricas cuando este pequeño contrato se entienda bien.