Dlaczego warto używać interceptorów w Axios

Interceptory axios to funkcje uruchamiane przed wysłaniem żądania lub po otrzymaniu odpowiedzi — wzorzec podobny do middleware. Zastosowania: uwierzytelnianie (automatyczne doklejanie tokenów do każdego żądania), scentralizowana obsługa błędów, logowanie, transformacja danych, logika ponawiania i globalne wskaźniki ładowania. Axios pozostaje najpopularniejszym klientem HTTP w JavaScripcie, obok wbudowanego fetch i nowszych nakładek typu ky. Interceptory to jego najmocniejsza karta — pozwalają trzymać sprawy przekrojowe w jednym miejscu zamiast kopiować je przy każdym wywołaniu.

Dwa punkty zaczepienia:

• interceptor żądania — działa przed wysłaniem: modyfikuje konfigurację, nagłówki, parametry i ciało,
• interceptor odpowiedzi — działa po otrzymaniu odpowiedzi, zanim trafi ona do kodu wywołującego: przetwarza dane, obsługuje błędy.

Kanoniczny przykład: axios.interceptors.request.use(config => { config.headers.Authorization = `Bearer ${token}`; return config; }) dokleja token do każdego żądania. Obsługę błędów realizuje interceptor odpowiedzi — jedno miejsce na reakcję na 401, komunikaty i logowanie zamiast rozsianych try/catchy. Zasada: interceptory do spraw przekrojowych, nie do logiki biznesowej.

Typowe scenariusze:

• uwierzytelnianie — automatyczne doklejanie tokenów JWT i OAuth,
• odświeżanie tokenów — wykrycie wygaśnięcia, odświeżenie i ponowienie pierwotnego żądania,
• obsługa błędów — scentralizowane toasty, logowanie, przekierowania przy 401,
• wskaźniki ładowania — globalny stan na podstawie liczby trwających żądań,
• ponawianie — automatyczne retry przy błędach sieciowych,
• transformacja danych — konwencje camelCase/snake_case, parsowanie dat i kwot,
• logowanie żądań pod debugowanie i zgodność.

Przy integracjach z rodzimymi API — bramkami płatności, KSeF, systemami bankowymi — interceptory obsługują uwierzytelnianie i ponowienia w jednym miejscu.

Kanon:

• token: axios.interceptors.request.use(config => { const token = localStorage.getItem("token"); if (token) config.headers.Authorization = `Bearer ${token}`; return config; }),
• obsługa 401: axios.interceptors.response.use(r => r, error => { if (error.response?.status === 401) logout(); return Promise.reject(error); }),
• odświeżanie tokenu — wzorzec złożony: wykryj 401, odśwież, ponów żądanie; gotowe rozwiązanie to biblioteka axios-auth-refresh,
• ponawianie — axios-retry zamiast własnej implementacji.

Warto też znać nowoczesną alternatywę: TanStack Query opakowuje axios/fetch i dostarcza retry, cache i obsługę błędów z pudełka — interceptory zostają wtedy dla warstwy autoryzacji.

W aplikacjach z wieloma wywołaniami API — zdecydowanie. Zyski: sprawy przekrojowe (tokeny, błędy, logowanie) w jednym miejscu, mniej duplikacji i łatwiejsze utrzymanie. Koszty: zachowanie „ukryte" w interceptorach bywa zaskoczeniem przy debugowaniu, a wzorce typu odświeżania tokenów mają swoje pułapki — stąd przewaga sprawdzonych bibliotek nad własnymi implementacjami. Zdrowa architektura warstwy HTTP w nowoczesnej aplikacji: axios z interceptorami do autoryzacji i błędów, TanStack Query do stanu serwera (cache, retry, invalidacja) — ten duet pokrywa niemal wszystkie potrzeby i jest dziś standardem profesjonalnego frontendu.