UD4 · Guía y taller práctico
El DOM: la web que responde
Conectamos las tres capas. El catálogo que en la UD3 vivía en la consola pasa a pintarse en la página, a filtrarse desde un formulario y a llegar desde un servidor. Con una regla que no se negocia: los datos mandan, y la página es solo su reflejo.
Antes de empezar
- Necesitas
- El sitio de la UD1 y la UD2 y el módulo de catálogo de la UD3.
- Visual Studio Code y un servidor local, como Live Server.
- Un navegador moderno con DevTools: consola, Elements, Sources y Network.
- Un lector de pantalla o, como mínimo, la navegación completa con teclado.
- Debes saber
- HTML semántico, formularios y atributos de accesibilidad (UD1).
- Selectores, clases y estados visuales en CSS (UD2).
- Funciones, arrays de objetos, métodos declarativos, módulos y JSON (UD3).
- Depurar con consola y puntos de interrupción (UD3).
¿Qué vas a aprender?
En la UD3 escribiste un catálogo que funciona, filtra, ordena y busca, pero su resultado solo se ha observado en la consola.
Esta unidad conecta ese código con la página. Al terminarla, escribir en un campo filtrará el catálogo mientras escribes, pulsar un botón cambiará el orden, enviar un formulario mostrará errores útiles, y los productos llegarán desde un servidor en vez de estar escritos a mano.
- HTML de la UD1
- CSS de la UD2
- Lógica de la UD3
- DOM y eventos
La idea que gobierna la unidad
Hay dos maneras de programar una interfaz. La primera es la que sale sola: cada vez que ocurre algo, buscar el trozo de página afectado y retocarlo a mano. Funciona con dos elementos y se vuelve ingobernable con diez, porque el estado real acaba repartido entre el HTML, tres variables y la memoria de quien lo escribió.
La segunda es la que aprenderemos:
Los datos mandan; la página es su reflejo
Hay un sitio donde vive la verdad: un objeto de estado en JavaScript. Cuando algo cambia, se modifica el estado y se vuelve a pintar a partir de él.
Nunca se pregunta a la página qué está pasando. Si necesitas saber qué filtro está activo, la respuesta está en tu estado, no en qué botón tiene una clase puesta.
- Ocurre un evento
- Cambia el estado
- Se vuelve a pintar
Esta forma de trabajar es la misma que usan React, Vue y Angular. No vamos a usar ninguno: vamos a hacerlo a mano para que, cuando llegue el framework, reconozcas qué te está resolviendo.
El proyecto continúa
El mismo sitio, con la carpeta js/ creciendo:
mi-web/
│
├── index.html
├── productos.html ← la página que más cambia
├── contacto.html
│
├── css/
│ └── styles.css
│
├── js/
│ ├── datos.js ← de la UD3
│ ├── catalogo.js ← de la UD3, casi sin tocar
│ ├── formato.js
│ ├── estado.js ← nuevo
│ ├── render.js ← nuevo
│ ├── eventos.js ← nuevo
│ └── main.js
│
└── img/Conviene observar un detalle relevante: catalogo.js apenas se modifica. Las funciones que escribiste en la UD3 siguen siendo válidas sin cambio alguno, porque devuelven datos en lugar de imprimirlos. Esa es la consecuencia de haberlas diseñado así.
Una página de productos que se genera desde datos, con búsqueda en vivo, dos filtros y una ordenación; un formulario de contacto validado y accesible; las preferencias del usuario recordadas entre visitas; y el catálogo cargado desde una API con sus tres estados: cargando, error y sin resultados.
Condición 1 · sin frameworks ni librerías
Ni React, ni Vue, ni jQuery. Todo con el DOM del navegador. Cuando en el módulo de servidor conectes con Angular sabrás exactamente qué parte del trabajo te está haciendo.
Condición 2 · la página sigue funcionando sin JavaScript
El HTML tiene que seguir siendo válido y navegable: los enlaces enlazan, el formulario tiene su acción, y el contenido esencial no depende de que el código se ejecute. JavaScript mejora la página; no la sustituye.
Es una decisión de accesibilidad y de robustez: una red lenta, un error de script o un bloqueador dejarían tu web en blanco.
Condición 3 · la IA, para entender, no para entregar
- Antes de preguntar: di si el evento llega o no. Un
console.logdentro del manejador separa «no salta» de «salta pero falla». - Pregunta: pide una explicación o una pista. Ejemplo: «Mis botones creados después de cargar no responden al clic. Los que estaban en el HTML sí. Explícame por qué sin darme el código».
- Después: cierra la respuesta y haz una variante distinta.
Herramientas
Dos pestañas de DevTools que hasta ahora usabas poco pasan al primer plano:
Elements
Muestra el DOM en vivo, no tu fichero. Ahí verás aparecer y desaparecer los elementos que crea tu código, y podrás comprobar si una clase se puso de verdad.
Network
Cada petición que hace la página: la URL, el estado, el tiempo y lo que devolvió. En la semana 5 es imprescindible para saber si el problema es tuyo o del servidor.
No todo pesa lo mismo
fetch.
localStorage, estados de carga y error, foco y teclado.
template, IntersectionObserver, AbortController y animaciones.
Plan de trabajo semanal
| Semana | Bloque temático | Práctica central | Horas |
|---|---|---|---|
| Semana 1 | La página como objetos | Seleccionar y modificar el documento | 3 h |
| Semana 2 | Eventos y elementos dinámicos | Responder al usuario y crear contenido | 3 h |
| Semana 3 | Pintar desde datos | Render del catálogo y formularios | 3 h |
| Semana 4 | Estado y persistencia | Filtros en vivo y preferencias guardadas | 3 h |
| Semana 5 | Datos remotos | Asincronía, fetch y sus tres estados |
3 h |
| Semana 6 | Interfaz robusta y entrega | Accesibilidad, depuración y revisión por pares | 3 h |
| Total | Una interfaz completa gobernada por datos | 18 h |
- Recupera · 5 min
- Aprende y observa · 10–20 min
- Practica · 30–40 min
- Cierra · 5 min
Sesiones de la unidad
Cada sesión es una clase, con su propia página.
18 sesiones
Semana 1 · La página como objetos
Semana 2 · Eventos y elementos dinámicos
Semana 3 · Pintar desde datos
Semana 4 · Estado y persistencia
Semana 5 · Datos remotos
Semana 6 · Interfaz robusta y entrega