Las promesas llegaron con ES6 para resolver uno de los problemas más frustrantes del desarrollo asíncrono en JavaScript: el callback hell. Ese código anidado, ilegible y difícil de mantener queda atrás cuando comprendes cómo funcionan las promesas, sus estados y la forma correcta de consumirlas.
¿Qué es una promesa y por qué cambia todo?
Una promesa es un objeto que representa el resultado eventual de una operación asíncrona [0:08]. No es el resultado en sí, sino la garantía de que ese resultado va a llegar o de que algo va a fallar. Una analogía útil: cuando pides comida a domicilio, la app te entrega un número de seguimiento. Ese número no es la comida, es la promesa de que te va a llegar.
Para crear una promesa se utiliza la palabra clave new Promise, que recibe dos argumentos: resolve y reject [0:45].
javascript
const miPromesa = new Promise((resolve, reject) => {
setTimeout(() => {
const exito = true;
if (exito) {
resolve('La operación fue exitosa');
} else {
reject('La operación falló');
}
}, 2000);
});
console.log(miPromesa);
Al ejecutar console.log(miPromesa) de forma inmediata, el resultado muestra una promesa en estado pending [1:10]. Esto sucede porque el setTimeout aún no ha terminado y la promesa todavía no se ha resuelto ni rechazado.
¿Cuáles son los tres estados de una promesa?
Toda promesa solo puede existir en uno de tres estados y solo transiciona en una dirección [1:18]:
- Pending: estado inicial, la operación aún no terminó.
- Fulfilled: la promesa se resolvió con éxito mediante
resolve.
- Rejected: la promesa falló y se ejecutó
reject.
Una vez que una promesa pasa a fulfilled o rejected, no puede cambiar de estado. Es inmutable [1:40]. Esta es una diferencia fundamental con los callbacks, donde nada impide llamar al callback dos veces.
javascript
const promesa = new Promise((resolve, reject) => {
resolve('Primer valor');
resolve('Segundo valor'); // ignorado
reject('Error'); // ignorado
});
Solo se respeta el primer resolve; todo lo demás es completamente ignorado [1:55].
¿Cómo se consumen las promesas con then y catch?
Para acceder al valor futuro que entrega una promesa se utilizan los métodos .then() y .catch() [2:10].
javascript
function obtenerNombre() {
return new Promise((resolve, reject) => {
setTimeout(() => {
const hayError = true;
if (hayError) {
reject('Algo salió mal');
} else {
resolve('María');
}
}, 1000);
});
}
obtenerNombre()
.then((nombre) => console.log(Hola, ${nombre}))
.catch((error) => console.log(error));
- Cuando
hayError es true, se ejecuta .catch() e imprime "Algo salió mal" [2:40].
- Cuando
hayError es false, se ejecuta .then() e imprime "Hola, María" [2:50].
¿Cómo se aplican las promesas en una API real?
Un caso práctico es consumir una API con fetch, que retorna una promesa de forma nativa [3:00].
javascript
fetch('https://api-colombia.com/api/v1/Department')
.then((respuesta) => respuesta.json())
.then((departamentos) => {
console.log(departamentos[0].name);
departamentos.forEach((dep) => {
console.log(${dep.name} - Población: ${dep.population});
});
})
.catch((error) => console.log('Error consultando la API de Colombia', error));
El primer .then() convierte la respuesta a JSON. El segundo .then() accede a los datos y recorre cada departamento imprimiendo su nombre y población [3:20]. El resultado muestra que el primer departamento es Arauca, seguido de todos los demás con su respectiva población.
¿Qué ocurre cuando un error no se maneja correctamente?
Si se intenta acceder a un índice inexistente, como departamentos[35], se obtiene un TypeError porque no se pueden leer propiedades de undefined [3:55]. El bloque .catch() captura ese error y lo muestra con el mensaje personalizado.
Entender que una promesa nace en pending y termina en fulfilled o rejected sin posibilidad de retroceder es la base para trabajar con código asíncrono limpio y predecible. ¿Ya has tenido problemas con promesas encadenadas? Comparte tu experiencia en los comentarios.
