Marc Semper Lloret
← El DOM: la web que responde

UD4 · Guía y taller práctico

Lo que debes recordar

El método

Cómo se construye una interfaz
  1. ¿Qué información necesito para pintar esto? Ese es el estado
  2. ¿Qué acciones lo cambian? Esos son los eventos
  3. ¿Cómo se ve el estado? Esa es la función de render
  4. ¿Qué pasa mientras carga, si falla, y si no hay nada?

Para depurar:

Cuando algo no responde
  1. ¿Llega el evento?
  2. Si no: ¿existe el elemento? ¿se creó después?
  3. Si sí: ¿los datos son los que crees, y del tipo que crees?
  4. ¿El estado es correcto y el fallo está solo al pintar?

La idea más importante

Los datos mandan; la página es su reflejo. Cuando algo cambia, cambia el estado y se vuelve a pintar.

De ahí sale todo lo demás: por eso no se lee el DOM para tomar decisiones, por eso el render es idempotente, por eso se delegan los eventos, y por eso la lógica de la UD3 sigue sin saber que existe una página.

No memorices el DOM

  • ¿Qué información necesita esta vista para existir?
  • ¿Dónde vive la verdad de este dato?
  • ¿Esto lo estoy leyendo del DOM en vez de del estado?
  • ¿Este elemento existía cuando registré la escucha?
  • ¿De qué tipo llega este valor de verdad?
  • ¿Qué se ve mientras esto carga? ¿Y si falla? ¿Y si está vacío?
  • ¿Esto se puede hacer sin ratón?
  • ¿Dónde queda el foco después de este cambio?
  • ¿Se entera de esto quien no ve la pantalla?

Al terminar deberías poder responder

  1. ¿Qué es el DOM y en qué se diferencia de tu fichero HTML?
  2. ¿Por qué el código debe esperar a que el documento exista?
  3. ¿Qué devuelve querySelector cuando no encuentra nada? ¿Y querySelectorAll?
  4. ¿Por qué seleccionamos con atributos data- y no con clases de CSS?
  5. ¿Por qué textContent es la opción por defecto frente a innerHTML?
  6. ¿Por qué JavaScript pone clases en vez de estilos?
  7. ¿Qué tres piezas tiene una escucha de eventos?
  8. ¿Por qué se escucha submit en el formulario y no el clic del botón?
  9. ¿Qué hace preventDefault?
  10. ¿Qué diferencia hay entre target y currentTarget?
  11. ¿Qué es el burbujeo y para qué sirve?
  12. ¿Qué ventajas tiene delegar eventos?
  13. ¿Para qué sirve closest?
  14. ¿Por qué se insertan los elementos con un fragmento?
  15. ¿Qué significa que un render sea idempotente?
  16. ¿Qué debe mostrar una lista vacía?
  17. ¿De qué tipo es el valor de un campo de formulario?
  18. ¿Qué recoge FormData y de qué depende?
  19. ¿Qué tres validaciones existen y cuál es obligatoria?
  20. ¿Qué hacen aria-describedby, aria-invalid y role="alert"?
  21. ¿Qué es el estado de una interfaz y por qué debe ser único?
  22. ¿Qué hacen exactamente tus manejadores de eventos?
  23. ¿Qué es un debounce y cuándo hace falta?
  24. ¿Para qué sirve aria-live?
  25. ¿Qué guarda localStorage y qué no debe guardarse ahí?
  26. ¿Por qué se lee lo guardado dentro de un try/catch?
  27. ¿Por qué JavaScript no espera a las operaciones lentas?
  28. ¿Qué es una promesa y qué dos finales tiene?
  29. ¿Qué hace await y dónde puede escribirse?
  30. ¿Por qué un 404 no rechaza la promesa de fetch?
  31. ¿Cuáles son los cuatro estados de una carga?
  32. ¿Qué es un error de CORS y dónde se resuelve?
  33. ¿Dónde debe quedar el foco tras volver a pintar?

El vocabulario de la unidad

Concepto Significa
DOM El documento convertido en árbol de objetos en memoria
Nodo / elemento Cualquier pieza del árbol / las que son etiquetas
NodeList Lo que devuelve una selección múltiple; no es un array
dataset Acceso a los atributos data-, siempre como texto
Evento Algo que ocurre y a lo que se puede reaccionar
Manejador La función que se ejecuta cuando ocurre
Burbujeo El ascenso del evento por el árbol hasta el documento
Delegación Escuchar en el contenedor y filtrar por el origen
Fragmento Un contenedor temporal para insertar de una vez
Render Generar la página a partir de los datos
Idempotente Que ejecutarlo dos veces deje el mismo resultado
Estado Todo lo necesario para saber cómo debe verse la interfaz
Fuente de verdad El único sitio donde vive un dato
Debounce Agrupar una ráfaga de eventos en una sola ejecución
Región activa Zona cuyos cambios anuncia el lector de pantalla
localStorage Almacén de texto del navegador, persistente
Asíncrono Que su resultado llega después, sin bloquear
Bucle de eventos El mecanismo que ejecuta lo que quedó en cola
Promesa Un valor futuro, que se cumple o se rechaza
fetch La forma de pedir datos a un servidor
CORS La política del navegador sobre peticiones a otro origen

La siguiente unidad

Tu web ya se comporta como una aplicación: pinta desde datos, reacciona, valida, recuerda y pide información a un servidor.

A un servidor que no es tuyo.

Lo que falta
  1. Cliente · lo que ya sabes
  2. HTTP · lo que viaja
  3. Servidor · lo que viene

En el tercer trimestre el mismo lenguaje se sale del navegador. Con Node.js escribirás programas que leen ficheros, atienden peticiones y responden; y en la UD6 construirás la API que hoy estás consumiendo. La /api/productos que has llamado con fetch la vas a escribir tú.

Ya deberías ser capaz de

  • Explicar qué es el DOM y en qué se diferencia del fichero HTML que escribiste.
  • Seleccionar elementos con precisión y sin depender de la posición que ocupan.
  • Modificar contenido, clases y atributos sin reescribir la estructura de la página.
  • Responder a lo que hace la persona usuaria con eventos, y usar delegación cuando el contenido es dinámico.
  • Generar la interfaz a partir de un array de datos, en lugar de escribirla a mano.
  • Mantener una única fuente de verdad y volver a pintar cuando el estado cambia.
  • Validar un formulario desde JavaScript sin romper la accesibilidad ni la validación nativa.
  • Guardar preferencias en el navegador y recuperarlas al volver.
  • Consumir una API con fetch y async/await, tratando la carga, el error y la lista vacía.
  • Depurar una interfaz distinguiendo un fallo del evento de un fallo de la lógica.