𝗔𝗻𝗴𝘂𝗹𝗮𝗿 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝘀𝗶𝗻𝗱 𝗻𝗶𝗰𝗵𝘁 𝗳𝘂̈𝗿 𝗚𝘂𝗮𝗿𝗱𝘀 𝗴𝗲𝗲𝗶𝗴𝗻𝗲𝘁
Angular 22 hat die stabile Resource API eingeführt. Dieses Tool hilft Ihnen dabei, APIs abzufragen und Lade- oder Fehlerzustände zu verfolgen. Es eignet sich gut für viele Aufgaben.
Verwenden Sie sie jedoch nicht in Guards oder Resolvers.
Guards und Resolvers blockieren die Navigation. Ein Guard prüft, ob ein Benutzer auf eine Route zugreifen kann. Ein Resolver ruft Daten ab, bevor eine Komponente geladen wird. Beide benötigen einen Boolean, ein Promise oder ein Observable, um ihre Logik abzuschließen.
Resources gehören zur Signals API. Signals sind reaktiv. Sie geben Werte nicht synchron zurück. Wenn Sie eine Resource erstellen, beginnt der Wert als undefined. Er wechselt dann in einen Ladezustand.
Schauen Sie sich diesen Fehler an:
export const authGuard: CanActivateFn = () => {
const authResource = httpResource<boolean>(() => ({
url: '/api/auth/status',
}));
return authResource.value() ?? false;
};
Die .value()-Methode gibt den aktuellen Signal-Wert sofort zurück. Da der API-Aufruf Zeit benötigt, ist der Wert zu Beginn undefined. Der Guard sieht undefined, behandelt dies als false und bricht die Navigation ab. Die App wartet nie auf die API.
Um dies zu beheben, müssen Sie die Resource in ein Observable umwandeln. Dies fügt unnötige Komplexität hinzu.
Guards müssen ein einzelnes asynchrones Ereignis repräsentieren. Verwenden Sie hierfür HttpClient mit Observables oder die native fetch API mit Promises.
Der richtige Weg:
export const authGuard: CanActivateFn = () => {
const http = inject(HttpClient);
return http.get<boolean>('/api/auth/status');
};
Das Observable weist den Router an, zu warten, bis die Anfrage abgeschlossen ist.
Verwenden Sie die Resource API für Komponenten und Services. Sie eignet sich hervorragend, um asynchrone Daten an Ihre Templates zu binden. Nutzen Sie Promises und Observables für Ihre Router-Logik.
Source: https://dev.to/geromegrignon/angular-resources-are-not-a-good-fit-for-guards-58j