Asincronía, AJAX y Frameworks

1. Por qué JavaScript no espera

JavaScript ejecuta tu código en un único hilo: hace una cosa detrás de otra. Si una operación lenta, como pedir datos a un servidor que tarda dos segundos en responder, bloqueara ese hilo, la página se quedaría congelada: no respondería a los clics, no podría hacer scroll y el navegador acabaría preguntando si quieres cerrarla. Por eso las operaciones lentas son asíncronas: se ponen en marcha, el código sigue, y cuando terminan se ejecuta lo que hayas dejado preparado.

Ese mecanismo se llama bucle de eventos (event loop). Una consecuencia práctica que sorprende al principio: aunque un setTimeout tenga 0 milisegundos de espera, su función no se ejecuta hasta que termina todo el código que se está ejecutando en ese momento.

1console.log("1. Pido los datos");
2setTimeout(() => console.log("3. Han llegado los datos"), 0);
3console.log("2. Mientras tanto, sigo trabajando");
4// Se imprime 1, 2, 3

2. De los callbacks a las promesas

La primera forma de manejar la asincronía fueron los callbacks: le pasas a la operación una función para que la llame al terminar. Funciona, pero cuando una operación depende de otra, que depende de otra, el código se anida hacia la derecha hasta volverse ilegible, lo que se conoce como callback hell.

Las promesas resolvieron el problema. Una promesa es un objeto que representa un resultado que todavía no existe: empieza pendiente y acaba cumplida (con un valor) o rechazada (con un error). Con then dices qué hacer con el valor, con catch qué hacer si falla y con finally qué hacer en cualquier caso. Y como then devuelve otra promesa, las operaciones se encadenan en vertical, no en escalera.

3. async y await: asincronía que se lee de arriba abajo

async y await son la forma moderna de trabajar con promesas. Una función marcada con async siempre devuelve una promesa, y dentro de ella await pausa la función (solo la función, no la página) hasta que la promesa se resuelve. El resultado es código asíncrono que se lee como si fuera secuencial, y los errores se capturan con el try/catch de toda la vida.

1async function mostrarPedido(id) {
2  try {
3    const respuesta = await fetch("/api/pedidos/" + id);
4    if (!respuesta.ok) throw new Error("El servidor respondió " + respuesta.status);
5    const pedido = await respuesta.json();
6    pintarPedido(pedido);
7  } catch (error) {
8    mostrarError("No se pudo cargar el pedido");
9    console.error(error);
10  }
11}

Errores típicos con await

• Olvidar el await. Sin él obtienes una promesa pendiente en lugar del dato, y verás cosas como [object Promise] en pantalla.
• Esperar en serie lo que podría ir en paralelo. Dos await seguidos hacen que la segunda petición no empiece hasta que acabe la primera. Si no dependen una de otra, usa Promise.all.
• await dentro de forEach. forEach no espera a las funciones async. Usa for…of si las quieres en orden, o Promise.all(lista.map(…)) si pueden ir a la vez.

4. AJAX con fetch

AJAX es el nombre que se dio en 2005 a la idea que cambió la web: pedir datos al servidor en segundo plano y actualizar solo una parte de la página, sin recargarla. Gmail y Google Maps la popularizaron. La «X» viene de XML, pero hoy los datos viajan casi siempre en JSON, y el viejo XMLHttpRequest ha dado paso a fetch, más sencillo y basado en promesas.

1// GET: leer datos
2const respuesta = await fetch("/api/productos?categoria=teclados");
3const productos = await respuesta.json();
4
5// POST: enviar datos en JSON
6await fetch("/api/productos", {
7  method: "POST",
8  headers: { "Content-Type": "application/json" },
9  body: JSON.stringify({ nombre: "Teclado mecánico", precio: 59.9 }),
10});
11
12// Con tiempo máximo: cancela si tarda más de 5 segundos
13const lenta = await fetch("/api/informe", { signal: AbortSignal.timeout(5000) });

CORS: por qué a veces el navegador bloquea la petición

Por seguridad, el navegador solo deja que tu página lea respuestas de su propio origen (mismo protocolo, dominio y puerto). Si tu web en miapp.com pide datos a api.otro.com, el navegador hace la petición pero solo te deja leer la respuesta si el servidor lo autoriza con la cabecera Access-Control-Allow-Origin. Cuando veas un error de CORS en la consola, recuerda que no se arregla en el cliente: es el servidor quien tiene que dar permiso.

Los cuatro estados de una pantalla con datos

Una buena interfaz no piensa solo en el caso feliz. Cada vez que cargas datos, tu pantalla puede estar en uno de cuatro estados, y el usuario debe saber siempre en cuál está: cargando (un indicador o un esqueleto), error (un mensaje comprensible y, si se puede, un botón para reintentar), vacío («no hay resultados», mejor que una lista en blanco) y con datos.

(sin mensajes)

5. Librerías y frameworks

Con lo visto hasta aquí puedes construir cualquier cosa. Pero en una aplicación grande, mantener sincronizados los datos y el DOM a mano se vuelve agotador: cada cambio obliga a recordar qué partes de la pantalla hay que actualizar. Los frameworks resuelven justo eso con una idea común: tú describes cómo se ve la interfaz en función del estado, y cuando el estado cambia, el framework actualiza el DOM por ti.

1import { useState } from "react";
2
3export function Contador() {
4  const [valor, setValor] = useState(0);
5  return (
6    <button onClick={() => setValor(valor + 1)}>
7      Has pulsado {valor} veces
8    </button>
9  );
10}

¿Cuál aprender? En España, React es el que más ofertas de empleo tiene, seguido de Angular. Pero lo más valioso es dominar primero JavaScript sin frameworks: los frameworks cambian cada pocos años y el lenguaje permanece. Quien entiende el DOM, los eventos y las promesas aprende cualquier framework en semanas.

6. Retos

En estos retos la página habla con un servidor simulado que responde con un pequeño retraso, igual que uno real. Las pruebas comprueban no solo que los datos lleguen, sino también cómo los pides: en paralelo, con el método y las cabeceras correctas, y cancelando lo que ya no hace falta.