Una petición no es instantánea
Pedir datos a una API tarda: viajan por la red, el backend trabaja, vuelven. Durante ese tiempo tu interfaz no puede quedarse en blanco. Toda llamada a una API atraviesa tres estados y la UI debe contemplar los tres:
- Cargando — la petición salió, aún no hay respuesta. Muestra un spinner o un esqueleto.
- Error — la respuesta falló (red caída,
404,500). Muestra un mensaje y, si procede, un botón de reintentar. - Datos — llegó la respuesta correcta. Renderiza el contenido.
async function cargar(api) {
// estado: cargando
try {
const datos = await api("/usuarios");
return { estado: "datos", datos }; // estado: datos
} catch (e) {
return { estado: "error", error: e.message }; // estado: error
}
}
Por qué importa el try/catch
Si no capturas el error, una API caída rompe la interfaz: la promesa se
rechaza, el render falla y el usuario ve una pantalla rota sin saber qué pasó.
Envolver la llamada en try/catch convierte un fallo de red en un estado
que sabes pintar.
Adaptar la respuesta a la UI
La forma que devuelve la API rara vez es la que tu interfaz necesita pintar.
Es buena práctica adaptar (mapear) la respuesta a la forma que consume la
UI, en una sola capa, en lugar de esparcir usuario.datos_personales.nombre
por toda la aplicación:
function adaptarUsuario(u) {
return { id: u.id, nombre: u.nombre_completo, activo: u.estado === "ACTIVO" };
}
Así, si el contrato del backend cambia, solo retocas el adaptador y el resto de la UI sigue intacta.
En el siguiente módulo verás la otra pieza de conectar front y back: la autenticación con tokens (JWT), para que el backend sepa quién hace cada petición.