Resolvers: los datos listos antes de entrar a la página

Cuando una página necesita datos de una API, tienes dos opciones: mostrarla vacía y cargar los datos DESPUÉS (con un "cargando…" parpadeante), o cargar los datos ANTES y mostrar la página ya lista. Un RESOLVER hace lo segundo: precarga los datos durante la navegación, de modo que el componente nace con todo en mano. Es una función —como los guards— y cierra tu caja de herramientas de routing. Hoy sabes cuándo y cómo usarlo.

El plato servido antes de sentarte

Un resolver funcional

Un resolver es una función ResolveFn<T> que devuelve los datos (o una Promise/Observable de ellos). Angular espera a que resuelva antes de activar la ruta:

import { inject } from '@angular/core';
import { ResolveFn } from '@angular/router';
import { ApiGastosService } from './api-gastos.service';
import { Gasto } from './gasto.model';

export const gastoResolver: ResolveFn<Gasto> = (route) => {
const api = inject(ApiGastosService);
const id = Number(route.paramMap.get('id'));
return api.obtener(id);   // Angular espera esta promesa antes de entrar
};

Lo conectas a la ruta con resolve, dándole un nombre a los datos:

{
path: 'gasto/:id',
resolve: { gasto: gastoResolver },   // 'gasto' estará listo al entrar
component: DetalleGastoComponent,
}

Y en el componente recibes el dato resuelto —con el binding de inputs, como un input() del mismo nombre que la clave (gasto)—:

@Component({
selector: 'app-detalle-gasto',
template: `<h2>{{ gasto().nombre }}</h2><p>{{ gasto().valor }} COP</p>`,
})
export class DetalleGastoComponent {
// el dato precargado por el resolver llega como input señal (sin "cargando")
gasto = input.required<Gasto>();
}

Como el resolver ya trajo el gasto, el template puede asumir que existe: nada de estados de carga ni @if de "cargando". La página nace completa.

Cuándo SÍ y cuándo NO usar un resolver

Antes vs Ahora

Mini-reto

Decide, para cada caso, si usarías un resolver o carga dentro del componente con resource(), y por qué: 1) el detalle de un gasto (datos pequeños, la página no existe sin él); 2) un dashboard con cinco widgets que cargan de endpoints distintos; 3) la ficha de un usuario que tarda ~2s en cargar desde un servicio externo lento. Escribe el ResolveFn del caso 1.

Qué sigue

Cierras la teoría de routing: rutas, parámetros como señales, lazy loading, guards y resolvers. Tienes todo para convertir componentes sueltos en una aplicación navegable y robusta. El reto del módulo lo junta: vas a diseñar el mapa de rutas de "Mi Bolsillo" con un guard de autenticación y la lógica de navegación, probando en vivo el corazón de todo: emparejar una URL con su ruta.