¿Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla?

"¿Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla?" toca un punto muy concreto de Angular: cómo tomar decisiones de enrutamiento sin esconder el problema bajo una abstracción vistosa.

La respuesta mejora cuando explicas qué parte del problema resuelves ahora con enrutamiento en Angular para "Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla", qué dejas derivado en resolvers y cómo detectarías pronto que la solución empieza a quedarse corta.

Qué evalúa el entrevistador

• Si distingues qué parte de "Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla" pertenece a enrutamiento y cuál debería resolverse en resolvers.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si sabes explicar qué ventaja real te aporta enrutamiento y qué coste de legibilidad, depuración o mantenimiento arrastra.

Respuesta sólida

• Explica la característica con un ejemplo concreto y después enlázala con legibilidad, coste de cambio y fallos frecuentes en producción.
• Compara la solución con una alternativa simple para dejar claro cuándo compensa usar enrutamiento y cuándo solo añade ruido.
• Si el lenguaje o framework ofrece varias rutas, justifica por qué elegirías una hoy y qué te haría revisarla mañana.

Compromisos y errores comunes

• La característica más elegante del lenguaje no siempre es la mejor para un equipo que necesita leer, depurar y evolucionar el código con rapidez.
• Usar un patrón porque suena avanzado es una mala señal si no mejora claridad, seguridad o velocidad de cambio.

Ejemplo de código

Este fragmento sirve para bajar "Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla" a código ejecutable y mostrar qué decisiones conviene hacer explícitas cuando enrutamiento empieza a cruzarse con resolvers.

import { ChangeDetectionStrategy, Component, computed, signal } from '@angular/core';

@Component({
  selector: 'app-product-filter',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input [value]="query()" (input)="query.set(($any($event.target)).value)" />
    <ul>
      @for (product of filteredProducts(); track product.id) {
        <li>{{ product.name }}</li>
      }
    </ul>
  `,
})
export class ProductFilterComponent {
  readonly query = signal('');
  readonly products = signal([{ id: 1, name: 'Angular' }, { id: 2, name: 'RxJS' }]);
  readonly filteredProducts = computed(() =>
    this.products().filter((product) =>
      product.name.toLowerCase().includes(this.query().trim().toLowerCase()),
    ),
  );
}

Fíjate en que el ejemplo deja claras las fronteras de "Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla", nombra los estados relevantes y evita trabajo implícito que luego cuesta depurar.

Ejemplo o caso real

Yo lo bajaría a un escenario reconocible de Angular: una pieza donde "Cuándo usarías un resolver y cuándo preferirías cargar datos dentro de la pantalla" aparece de forma recurrente, ya ha dejado señales en revisión o en soporte y mezcla enrutamiento con resolvers. Si la decisión mejora claridad, observabilidad y velocidad de cambio en ese trozo, entonces merece escalarla; si no, la dejaría local y documentada.

Frase corta de entrevista

Primero aclaro qué problema resuelvo con enrutamiento y luego elijo la técnica; no al revés.