Los recursos de Angular no son adecuados para los Guards

Los Angular Resources no son adecuados para los Guards

Angular 22 introdujo la Resource API estable. Esta herramienta te ayuda a consultar APIs y rastrear estados de carga o de error. Funciona bien para muchas tareas.

Sin embargo, no la uses en Guards o Resolvers.

Los Guards y Resolvers bloquean la navegación. Un Guard comprueba si un usuario puede acceder a una ruta. Un Resolver obtiene datos antes de que se cargue un componente. Ambos requieren un booleano, una Promise o un Observable para finalizar su lógica.

Los Resources pertenecen a la Signals API. Los Signals son reactivos. No devuelven valores de forma síncrona. Cuando creas un Resource, el valor comienza como undefined. Luego pasa a un estado de carga.

Mira este error:

export const authGuard: CanActivateFn = () => {
  const authResource = httpResource<boolean>(() => ({
    url: '/api/auth/status',
  }));

  return authResource.value() ?? false;
};

El método .value() devuelve el valor actual del signal inmediatamente. Debido a que la llamada a la API toma tiempo, el valor es undefined al inicio. El Guard ve undefined, lo trata como false y cancela la navegación. La aplicación nunca espera a la API.

Para solucionar esto, debes convertir el Resource en un Observable. Esto añade una complejidad innecesaria.

Los Guards deben representar un único evento asíncrono. Para ello, utiliza HttpClient con Observables o la API fetch nativa con Promises.

La forma correcta:

export const authGuard: CanActivateFn = () => {
  const http = inject(HttpClient);

  return http.get<boolean>('/api/auth/status');
};

El Observable le indica al Router que espere hasta que la solicitud se complete.

Utiliza la Resource API para componentes y servicios. Es ideal para vincular datos asíncronos a tus plantillas. Reserva las Promises y los Observables para tu lógica de Router.

Source: https://dev.to/geromegrignon/angular-resources-are-not-a-good-fit-for-guards-58j