React: un inbox de prueba con layout estable

Una bandeja de correo de prueba puede parecer un componente sencillo: un botón para iniciar la consulta, una lista de mensajes y un estado vacío. En la practica, los estados intermedios suelen causar más problemas que la lista final. Un spinner aparece, desaparece, mueve el botón y deja al equipo de QA buscando el mensaje en otra posición.

Este artículo propone un enfoque pequeño para React: reservar desde el principio el espacio de la bandeja, comunicar cada estado y mantener el foco donde el usuario espera. La idea sirve para flujos que revisan una dirección de correo desechable, un buzón de staging o cualquier integración de verificación por email.

El problema no es la bandeja: es el movimiento

Cuando una consulta tarda 300 ms, el cambio de layout casi no se nota. Si tarda dos segundos, el usuario ya ha empezado a leer otra cosa. Si falla y vuelve a intentarse, la interfaz puede cambiar tres veces: carga, vacío, error y finalmente mensajes.

Ese movimiento tiene un coste práctico. El clic siguiente ocurre sobre otro elemento, el lector de pantalla recibe anuncios poco claros y una captura de evidencia queda desactualizada. Además, cada prueba necesitan una forma visible de saber si el sistema sigue esperando o si ya terminó.

Por eso conviene modelar el inbox como una máquina de estados simple:

type InboxState =
  | { kind: "idle" }
  | { kind: "loading" }
  | { kind: "ready"; messages: Message[] }
  | { kind: "empty" }
  | { kind: "error"; message: string };

No hace falta enseñar todos los detalles internos. Basta con que la UI pueda distinguir una consulta que todavía no termina de una consulta que terminó sin mensajes.

Diseñar un estado estable antes de traer mensajes

El componente debe tener una estructura que no cambie entre estados. Un encabezado, una región de estado y una lista ocupan siempre el mismo lugar. El contenido de la lista sí puede variar, pero el botón de actualizar no debería saltar hacia arriba o abajo.

También es útil mostrar una explicación breve: “Buscando mensajes”, “No hay mensajes todavía” o “No pudimos consultar el buzón”. “Cargando” a secas informa poco, especialmente cuando la respuesta tarda mas de lo esperado.

Un ejemplo de renderizado legible podría ser:

function TestInbox({ state }: { state: InboxState }) {
  return (
    <section className="test-inbox" aria-labelledby="inbox-title">
      <div className="test-inbox__header">
        <h2 id="inbox-title">Correo de prueba</h2>
        <button type="button">Actualizar</button>
      </div>

      <p className="test-inbox__status" role="status" aria-live="polite">
        {statusText(state)}
      </p>

      <div className="test-inbox__viewport">
        {state.kind === "ready" && <MessageList messages={state.messages} />}
        {state.kind === "empty" && <EmptyState />}
        {state.kind === "error" && <ErrorState message={state.message} />}
      </div>
    </section>
  );
}

La región aria-live comunica el cambio sin robar el foco. El botón conserva su posición y puede seguir usándose con teclado. Si la consulta es larga, es mejor indicar progreso en ese texto que hacer que el lector de pantalla anuncian cada modificación de la lista.

CSS para reservar espacio sin ocultar información

La reserva de espacio no significa fingir que ya hay mensajes. Significa dar una altura mínima razonable al viewport y usar un estado vacío que explica qué está pasando. Así el layout permanece reconocible cuando llega la respuesta.

.test-inbox__viewport {
  min-height: 16rem;
  display: grid;
  align-content: start;
  gap: 0.75rem;
  padding: 1rem;
  border: 1px solid #d8dee9;
  border-radius: 0.75rem;
  background: #fff;
}

.test-inbox__status {
  min-height: 1.5rem;
  margin: 0.5rem 0;
  color: #52606d;
}

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    scroll-behavior: auto;
    transition-duration: 0.01ms;
  }
}

El min-height evita el salto principal y align-content: start mantiene el mensaje cerca del encabezado. En pantallas pequeñas, una altura mínima demasiado grande tambien puede ser incómoda; conviene probarla con zoom y con contenido largo, no solo en el viewport del portátil.

Este patrón combina bien con pruebas que necesitan esperar un mensaje concreto. Para separar la experiencia del frontend de la lógica del servicio, puedes probar correos de renovación en un SaaS y revisar el contrato de entrega en otra capa. Si el backend usa una espera asíncrona, también ayuda entender una espera útil para correos asíncronos antes de poner otro spinner en React.

Accesibilidad y rendimiento en la misma revisión

Una interfaz accesible no tiene que ser pesada. El componente puede mostrar una sola región viva, evitar animaciones permanentes y renderizar únicamente los mensajes visibles. Para una bandeja pequeña, eso es suficiente y mantiene el código mas claro.

Hay cuatro comprobaciones rápidas:

1. El foco queda en el botón después de actualizar, salvo que el usuario haya abierto un mensaje.
2. Un teclado puede iniciar una consulta, leer el estado y llegar a cada mensaje.
3. El texto de estado diferencia loading, empty y error; no todo es “sin resultados”.
4. El contraste sigue siendo legible en el estado deshabilitado y en el mensaje de error.

Si el equipo busca términos como dummy e mail o tem email durante una prueba de búsqueda, pueden aparecer como datos de fixture, pero no deberían colarse en etiquetas visibles de producción. Es mejor conservar esos valores en un escenario controlado y documentado.

Para flujos de QA que usan un correo temporal, el componente debería tratar el buzón como una fuente de evidencia de corta duración, no como un historial permanente. Guarda el identificador de la ejecución, el asunto esperado y la hora de consulta. No hace falta copiar todo el contenido del mensaje si solo se valida que llegó el enlace correcto.

Checklist para una sesión de QA

• [ ] El título y el botón no cambian de posición entre estados.
• [ ] La región de estado anuncia cambios útiles, no cada detalle técnico.
• [ ] El área de mensajes tiene una altura mínima y un estado vacío explicativo.
• [ ] La interfaz funciona con teclado, zoom y reducción de movimiento.
• [ ] La prueba identifica el mensaje por un dato estable, como un asunto o un token de ejecución.
• [ ] Los fallos dejan una evidencia que se puede leer sin repetir la consulta a ciegas.

Una bandeja de prueba bien diseñada no intenta ocultar la latencia. La hace comprensible. Con estados explícitos, CSS predecible y una revisión de accesibilidad desde el inicio, el equipo puede validar correo sin perseguir elementos que se mueven. Es una mejora sencilla y bastante util para cualquier frontend que dependa de mensajes asíncronos.