Hoy · Hoja de ruta
- 1. Aprende: Qué se revisa en una interfaz antes de darla por terminada.
- 2. Haz: Audita tu proyecto, revisa el de un compañero y corrige.
- 3. Comprueba: Puedes defender cada decisión.
La lista de auditoría
Auditoría · arquitectura
- Hay un único objeto de estado, y nada se decide leyendo el DOM.
- Los manejadores cambian el estado y llaman a actualizar.
- El render es idempotente: llamarlo dos veces no duplica nada.
- Las funciones de la UD3 siguen sin conocer el DOM.
- Hay una escucha delegada por contenedor, no una por elemento.
Auditoría · comportamiento
- Los cuatro estados están contemplados: cargando, error, vacío y datos.
- Toda petición comprueba
respuesta.ok. - Los valores de formulario se convierten al leerlos.
- Un valor guardado inválido no rompe la página.
- No hay errores en consola al cargar ni al usar la interfaz.
Auditoría · accesibilidad y calidad
- Todo se maneja con teclado y el foco siempre se ve.
- Los cambios de contenido se anuncian.
- El marcado generado es semántico y válido en el W3C.
- Los errores de formulario están asociados a su campo.
- No hay
innerHTMLcon datos de fuera. - No queda código de depuración ni comentado.
Revisión por pares
Intercambia proyectos y, sin preguntar nada:
- Usa la interfaz solo con el teclado y anota dónde te atascas.
- Simula red lenta y sin red, y describe qué ve el usuario.
- Busca algo que no exista y comprueba el estado vacío.
- Localiza en el código dónde vive el estado y explícalo.
- Señala una decisión bien tomada y una mejorable, con su razón.
Defensa
Las preguntas de la defensa
- Enséñame el estado de tu aplicación y explícame qué guarda cada campo.
- Escribe una letra en el buscador y cuéntame todo lo que ocurre, en orden.
- ¿Qué pasa si el servidor tarda cinco segundos? ¿Y si devuelve un 500?
- ¿Qué parte de tu código tendrías que cambiar si mañana los datos llegaran de otra API?
- Enséñame un fallo que te costó encontrar y cómo lo encontraste.
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».
Evaluación
| Criterio | Puntos |
|---|---|
| Render desde datos: idempotente y con su estado vacío | 2 |
| Estado único: ninguna decisión se toma leyendo el DOM | 2 |
| Eventos y delegación | 1,5 |
| Formulario validado con errores accesibles y foco correcto | 1,5 |
| Carga de datos con sus cuatro estados | 1,5 |
| Accesibilidad: teclado, foco y cambios anunciados | 1,5 |
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.
Entrega
El sitio completo con su carpeta js/ organizada en módulos; el catálogo cargado desde una API con sus cuatro estados; búsqueda, filtros y orden gobernados por un único estado; el formulario validado y accesible; las preferencias persistidas; las tres listas de auditoría marcadas; la revisión del compañero por escrito; y un NOTAS.md con las decisiones que tomaste y lo que dejaste fuera.
Microprueba semanal 6 · 10 minutos
Individual, sin IA y sin apuntes.
- Describe, en orden, todo lo que ocurre desde que se escribe una letra en el buscador hasta que cambia la lista.
- Un botón creado por tu código no responde. Escribe las tres comprobaciones, en orden.
- Señala dos decisiones de accesibilidad de tu interfaz y di a quién ayuda cada una.