Cuando el texto importante es el que desaparece

Una revisión de UI/UX en Greenhouse (mi app de gestión de proyectos creativos) encontró una tarjeta en el tablero kanban sin nombre. Solo una etiqueta de etapa, un chip de “abandonado por 300 días,” y una insignia “Disponible”, justo la única información que realmente identifica al proyecto había desaparecido.

El markup de la tarjeta coloca el nombre y una fila de chips de metadatos uno al lado del otro en una fila flexbox. Los chips no se achican (flex-shrink: 0) porque nadie quiere ver “Abandonado por 12d” recortado a “Abandonado por 1…”. El nombre se trunca con puntos suspensivos, lo cual es normal, se supone que los nombres se achican para caber. Pero flexbox no sabe que “achicarse con gracia” y “achicarse hasta nada” son resultados distintos. Una vez que el ancho propio de los metadatos consumió más espacio del que tenía el contenedor, todo el espacio faltante salió del nombre, y este siguió achicándose más allá de “todavía legible” hasta llegar a cero.

La solución es una línea: flex-wrap: wrap en la fila. Ahora, cuando ambas piezas no caben en una sola línea, los metadatos que no se achican bajan a su propia línea en vez de robarle ancho al nombre. El nombre recibe la fila completa y se trunca hasta algo que realmente se puede leer, o no necesita truncarse en absoluto. Sin JS, sin números mágicos de ancho mínimo que ajustar por vista, lo verifiqué contra los cuatro lugares donde se renderiza esta tarjeta (una columna kanban, una lista de panel de ancho normal, y otros dos) y se autoajusta a cada uno.

Mientras estaba ahí también noté que el tablero kanban mostraba un chip de etapa redundante en cada tarjeta, aunque la columna misma ya está etiquetada por etapa, puro desorden. Y no había ninguna pista visual de que un tablero con seis etapas tuviera dos columnas fuera de vista al borde derecho con un ancho de ventana normal. Corregí lo primero ocultando el chip específicamente en el tablero (una prop simple), y lo segundo con un truco ingenioso que no había usado antes: dos gradientes de fondo superpuestos, uno que se desplaza con el contenido y otro fijo al borde, de modo que aparece una sombra sutil exactamente cuando hay más para desplazar y desaparece cuando no lo hay. CSS puro, sin escuchadores de scroll.

La parte que realmente tomó tiempo fue demostrar que todo esto funcionaba. Mi suite de pruebas corre sobre jsdom, que no hace ningún layout, puede decir que un componente renderizó un <span> con el texto correcto adentro, pero no tiene idea de si ese span mide 400 píxeles de ancho o 0. Un bug de layout como este es invisible para una suite de pruebas en verde. Terminé conduciendo la app compilada real a través de el arnés de WebDriver, sembrando un proyecto con un nombre largo, empujándolo a la columna más angosta del tablero, y tomando una captura de pantalla real. Incluso así choqué con un muro al intentar demostrar que la sombra de scroll se actualiza en vivo, la herramienta de capturas no detectaba un cambio en scrollLeft que acababa de fijar y confirmar mediante una consulta al DOM en vivo. Muestrear los píxeles de la captura estática (la franja de color de la sombra estaba exactamente donde debía, justo en el borde con más contenido por delante) terminó siendo la verificación más confiable que el intento de “desplazar y volver a capturar.”

Un bug pequeño, pero un buen recordatorio: todo lo que toque “cuánto espacio recibe este elemento” necesita verificarse con layout real, no solo “el texto correcto terminó en el DOM.”