Interfaz robusta y entrega

Tres horas. Media hora para saber qué rompe JavaScript cuando se usa sin cuidado y cómo se ordena un diagnóstico, y dos horas y media auditando tu interfaz, montando una nueva y reparando una rota.

Se explica

25 minutos · conceptos y demostración

JavaScript es la capa que más fácilmente estropea lo que las dos anteriores hicieron bien. Hoy se nombran esos destrozos y se ordena el método para encontrarlos.

Lo que JavaScript rompe con facilidad

El foco después de pintar

function actualizar() {
  const activo = document.activeElement?.dataset.js;
  pintarCatalogo(aplicarFiltros(estado), elementos.catalogo);
  if (activo) elementos[activo]?.focus();
}

Al sustituir el contenido de un contenedor, el elemento que tenía el foco deja de existir y el foco vuelve al documento. Para quien navega con teclado eso significa empezar de cero cada vez que escribe una letra.

Las preferencias del sistema se respetan también desde el código, con la misma consulta que usaste en el CSS de la UD2:

const sinMovimiento = window.matchMedia("(prefers-reduced-motion: reduce)").matches;
if (!sinMovimiento) elemento.classList.add("con-animacion");

Rendimiento: las tres cosas que importan

1. No trabajar de más. Un debounce en lo que se dispara en ráfaga.
2. No tocar el DOM en bucle. Construir aparte, insertar una vez.
3. No mezclar leer y escribir. Leer una medida obliga al navegador a recalcular; hacerlo dentro de un bucle que además escribe multiplica ese coste.

// Costoso: lee y escribe alternativamente
for (const tarjeta of tarjetas) {
  tarjeta.style.setProperty("--alto", `${tarjeta.offsetHeight}px`);
}

// Mejor: primero se lee todo, después se escribe todo
const alturas = tarjetas.map((t) => t.offsetHeight);
tarjetas.forEach((t, i) => t.style.setProperty("--alto", `${alturas[i]}px`));

Con doscientas tarjetas la diferencia es perceptible; con dos mil, separa una interfaz fluida de una inutilizable.

Cómo se diagnostica una interfaz

Los fallos de esta unidad caen casi siempre en una de cinco familias, y cada una se busca en un sitio distinto:

Revisar una interfaz ajena

La revisión de hoy no se hace leyendo código, al menos no al principio. Se hace usándola:

1. Usar la interfaz solo con el teclado y anotar dónde se atasca uno.
2. Simular red lenta y sin red, y describir qué ve el usuario.
3. Buscar algo que no exista y comprobar el estado vacío.
4. Localizar en el código dónde vive el estado y explicarlo.
5. Señalar una decisión bien tomada y una mejorable, con su razón.

Los tres primeros puntos no requieren entender el código de nadie, y son los que encuentran más defectos.

Se trabaja

150 minutos · auditoría, interfaz nueva y diagnóstico

El primer paso arregla lo tuyo. El segundo y el tercero comprueban si sabrías hacerlo otra vez y repararlo cuando lo escribió otro.

Paso 1 · Auditoría de accesibilidad · 35 min

1. Recorre toda la interfaz con el tabulador y anota cada punto donde te pierdes.
2. Comprueba que ningún control es un contenedor genérico disfrazado.
3. Arregla el foco tras cada render.
4. Verifica que el resumen de resultados se anuncia.
5. Comprueba el contraste y la visibilidad del foco.
6. Mide con la pestaña Performance cuánto tarda un render de cien tarjetas, y aplica la separación entre lectura y escritura si mezclas las dos.

Antes de continuar: escribe una letra en el buscador y comprueba que el foco sigue dentro del campo después de que la lista se repinte.

Paso 2 · Una interfaz nueva · 45 min

Es el trabajo central de la sesión. Recibirás un fichero JSON de un dominio que no has visto —cartelera de cine, ofertas de empleo, rutas de senderismo— y una lista de requisitos.

1. Cargar los datos con fetch y sus cuatro estados
2. Pintar la lista desde los datos
3. Un buscador y dos filtros combinables
4. Estado único y render idempotente
5. Resultado anunciado y manejable con teclado

Sin copiar y pegar tu proyecto: puedes mirar tus apuntes, pero el código se escribe hoy. Empieza por el estado, no por el HTML: si sabes qué campos necesita, el resto se deduce.

Paso 3 · El diagnóstico · 30 min

Sobre una interfaz que viene con cinco fallos, uno de cada familia de la explicación. Lo que se evalúa es el diagnóstico, no la velocidad de corrección.

Rellena las tres primeras columnas antes de tocar nada. Si tu hipótesis resulta equivocada, no la borres: anota al lado por qué la descartaste. Esa columna es la que enseña a diagnosticar.

Paso 4 · La auditoría final · 20 min

Paso 5 · Revisión por pares y cierre de la entrega · 20 min

Intercambia proyectos y aplica los cinco puntos de la explicación, empezando por usar la interfaz sin ratón y con la red simulada. Devuelve las cinco respuestas por escrito, recibe la tuya y decide qué aceptas.

Prepara respuestas de un minuto para estas cinco preguntas:

La cuarta vuelve a ser la de siempre: si has separado datos, lógica, estado y render, la respuesta debería ser «solo la función que llama a fetch».

No puntúa que la interfaz sea vistosa. Puntúa que aguante: contenido que cambia, red que falla, búsquedas sin resultados y alguien que no usa el ratón.

Ampliación si has completado el trabajo

Primero termina la entrega. El primer reto es el componente más difícil de hacer accesible; el segundo convierte el diagnóstico en prevención.

Reto 1 · El panel que no deja escapar el foco

Un panel de filtros que se abre sobre el contenido es el ejemplo clásico de algo que funciona con ratón y es inservible sin él.

1. Móntalo con un botón que lo abre y un botón que lo cierra.
2. Al abrirlo, lleva el foco dentro. Decide a qué elemento y justifícalo.
3. Mientras está abierto, el tabulador no debe salir del panel: al llegar al último elemento vuelve al primero, y al revés con Shift + Tab. Impleméntalo.
4. Escape lo cierra, y al cerrarse el foco vuelve al botón que lo abrió, no al principio del documento.
5. Mientras está abierto, el contenido de detrás no debería ser alcanzable ni por el tabulador ni por un lector de pantalla. Averigua con qué atributo se marca eso.
6. Ahora busca el elemento HTML nativo que hace todo lo anterior sin una línea de JavaScript. Léelo, pruébalo, y escribe en tres líneas qué te ha costado reconstruir a mano de lo que él trae hecho. Es la misma lección de la UD1 con details y de la sesión 2 con el botón falso.

Reto 2 · La comprobación que lo habría delatado

Vuelve a los cinco fallos del paso 3. Para cada uno, añade al código una comprobación que lo hubiera hecho evidente en el momento de producirse.

Tres criterios para escribirlas:

1. Cerca del origen, no donde aparece el síntoma.
2. Ruidosas: que detengan o avisen de forma inequívoca, no un mensaje perdido entre otros cincuenta.
3. Que digan qué se esperaba, no solo que algo falló.

El quinto es el más interesante: una comprobación de idempotencia se puede escribir de verdad. Pinta dos veces con los mismos datos y compara el número de hijos del contenedor. Si no coincide, el render no era idempotente y el programa lo dice solo.

Cierre

5 minutos · comprobación y recuerdo

Ver respuestas

1 · En un punto con sentido: el control que se usó, el primer resultado o el mensaje que acaba de aparecer. Nunca al principio del documento.

2 · Por ejemplo: controles falsos, foco perdido, cambios que no se anuncian, foco invisible o movimiento no solicitado.

3 · Si el evento llega, con un mensaje en la primera línea del manejador.

4 · Selección, evento, tipo, asincronía y render.

5 · Porque leer una medida obliga al navegador a recalcular, y alternarlo con escrituras multiplica ese coste.

6 · Salta el evento input, el manejador cambia el estado, se llama a actualizar, se aplican los filtros sobre los datos, se vuelve a pintar el contenedor y se anuncia el número de resultados.

---