Angular resources are not a good fit for Guards

Angular 22 released a stable version of the Resource API, providing a complete API to query an API,...

Angular 22 released a stable version of the Resource API, providing a complete API to query an API, now including loading/errors states builtin and some other features to improve our dev experience.

One place in Angular apps where we need to make API calls are Guards... and Resolvers.

They both block a current navigation to resolve their internal logic:

• For Guards, the point is to prevent accessing the target route if falsy, used to prevent a user from accessing some route requiring to display data they are not allowed to (preventing UI errors as API calls will be rejected).
• For Resolvers, the idea is to retrieve some data before hitting the target route, to pass it to the router and get it ready as soon as the component is rendered.

They both block the navigation until their logic is resolved. For this reason they obviously return a boolean, a Promise<boolean>, or an Observable<boolean>.

Why the Angular Resource API Fails in Guards

Resources are part of the new Signals API, meant to provide a new reactive solution for Angular apps. But as being reactive, they do not synchronously return a value.

When you create a Resource, its initial value is undefined while it immediately transitions into a loading state.

Let's look at what happens if we try to use a Resource inside a Guard:

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

  // This returns the signal's current value synchronously
  // Which is `undefined` initially!
  return authResource.value() ?? false;
};

Because .value() is a Signal, reading it inside the Guard will synchronously return undefined (or whatever default value you provided). The Guard will immediately evaluate this to false and cancel the navigation instantly, without waiting for the API call to finish!

To make this work, you would have to jump through hoops to convert the Resource's status into an Observable, wait for it to stop loading, and then emit the value. This defeats the entire purpose of the simple Router Guard API.

The Right Approach: Observables and Promises

Since Guards and Resolvers are meant to represent a single asynchronous event that blocks navigation, traditional Promises or RxJS Observables remain the perfect tool for the job.

Instead of fighting against the reactive nature of Signals, stick to the HttpClient returning an Observable (or the native fetch API returning a Promise):

export const authGuard: CanActivateFn = () => {
  const http = inject(HttpClient);
  
  // An Observable cleanly blocks the Router until it completes or emits
  return http.get<boolean>('/api/auth/status');
};

Conclusion

The Resource API (resource and httpResource) is fantastic for components and services where you want to seamlessly bind async data to your templates while tracking loading and error states. However, Guards and Resolvers are fundamentally about blocking a process until a single async event completes.

For these Router mechanisms, Promises and Observables are precisely designed to handle that kind of control flow. Keep your Guards simple, and save the Resource API for your UI's reactive data needs!