Что такое Axios

Начните с прямого определения: Axios это библиотека для HTTP-запросов в JavaScript. Во фронтенде она часто работает как слой между UI и API. Компонент или сервис вызывает метод, Axios отправляет запрос, возвращает промис и дает доступ к данным ответа, статусу и заголовкам.

Не стоит отвечать так, будто Axios сам делает приложение надежным. Он только дает удобные инструменты. Вам все равно нужно решить, что показывать пользователю во время загрузки, как обработать ошибку, как отменить лишний запрос и как не отправить приватные данные туда, куда не нужно.

Можно ответить так:

Axios это библиотека для HTTP-запросов. Она работает через промисы, упрощает отправку запросов к API, умеет автоматически сериализовать и парсить JSON, поддерживает interceptors, отдельные instances, timeout и отмену запросов. Я использую ее, когда нужен единый API-клиент и централизованная обработка авторизации или ошибок.

Сразу добавьте практический вывод:

Но сам Axios не решает все сетевые проблемы. В UI все равно нужно обрабатывать loading, ошибки, отмену старых запросов и разные HTTP-статусы, иначе можно получить плохой UX или race condition.

Сравнивайте спокойно. fetch это встроенный браузерный API, а Axios это внешняя библиотека. Поэтому fetch хорош для простых сценариев и не добавляет зависимость. Axios удобен, когда нужен готовый клиент с общей конфигурацией.

Самая частая ловушка на интервью связана с HTTP-ошибками. Axios по умолчанию считает успешными только статусы 2xx. Если сервер вернул 404 или 500, промис будет отклонен. У fetch ответ с 404 обычно не попадает в catch, потому что запрос технически дошел до сервера. Там нужно проверять response.ok.

// fetch: 404 не обязательно попадет в catch
const response = await fetch("/api/users/42");

if (!response.ok) {
  throw new Error(`HTTP error: ${response.status}`);
}

const data = await response.json();

// axios: 404 по умолчанию попадет в catch
try {
  const response = await api.get("/users/42");
  console.log(response.data);
} catch (error) {
  console.error(error.response?.status);
}

Практический вывод простой. Если вы переходите с fetch на Axios или обратно, нельзя просто заменить синтаксис. Нужно проверить, как код определяет ошибку. Иначе UI может показать успех на ошибочном ответе или сломать общий обработчик.

В реальном проекте Axios чаще всего ценен не из-за короткого синтаксиса, а из-за повторного использования настроек. Например, можно создать отдельный клиент для API и не размазывать baseURL, timeout и заголовки по компонентам.

import axios from "axios";

export const api = axios.create({
  baseURL: "/api",
  timeout: 10_000,
});

api.interceptors.request.use((config) => {
  const token = getAccessToken();

  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }

  return config;
});

api.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response?.status === 401) {
      logoutUser();
    }

    return Promise.reject(error);
  }
);

Такой код лучше держать рядом с API-слоем, а не внутри UI-компонента. Иначе interceptor может зарегистрироваться несколько раз, начать дублировать действия и усложнить отладку.

В ответе полезно показать, что вы не ограничиваетесь фразой "добавлю catch". Ошибки бывают разными. Если есть error.response, сервер вернул ответ, и можно смотреть статус. Если есть error.request, ответ не пришел. Если нет ни того, ни другого, проблема могла быть в настройке запроса.

Для пользователя эти случаи выглядят по-разному. При 401 можно предложить войти снова, при 404 показать пустое состояние или сообщение "не найдено", при 409 объяснить конфликт данных, при timeout дать повторить запрос. Один общий toast "что-то пошло не так" быстро превращается в плохой UX и мешает поддержке.

В React запрос может устареть раньше, чем завершится. Например, пользователь печатает в поиске, меняет фильтр или уходит со страницы. Если старый ответ придет позже нового, он может перезаписать актуальные данные. Для живого поиска часто добавляют debounce, чтобы не слать запрос на каждую букву, а отмена защищает от устаревших ответов.

import { useEffect, useState } from "react";
import { api } from "./api";

export function UsersList({ query }) {
  const [users, setUsers] = useState([]);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    async function loadUsers() {
      setIsLoading(true);
      setError(null);

      try {
        const response = await api.get("/users", {
          params: { query },
          signal: controller.signal,
        });

        if (!Array.isArray(response.data)) {
          throw new Error("Unexpected users response");
        }

        setUsers(response.data);
      } catch (error) {
        if (controller.signal.aborted) {
          return;
        }

        setUsers([]);
        setError(error);
      } finally {
        if (!controller.signal.aborted) {
          setIsLoading(false);
        }
      }
    }

    loadUsers();

    return () => {
      controller.abort();
    };
  }, [query]);

  if (isLoading) {
    return <p role="status">Загружаем пользователей...</p>;
  }

  if (error) {
    return <p role="alert">Не удалось загрузить пользователей.</p>;
  }

  if (users.length === 0) {
    return <p>Пользователи не найдены.</p>;
  }

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

Здесь важна не сама библиотека, а правило: запрос, который больше не нужен, не должен обновлять UI. Пример также разделяет loading, error и empty state. Это защищает от зависшего интерфейса, race condition и тихого падения при неожиданном формате ответа. На интервью это звучит сильнее, чем просто "Axios поддерживает отмену".

Если вас просят привести практический пример использования Axios, не ограничивайтесь axios.get. Покажите, что умеете строить безопасный слой API: отдельный instance, единый формат ошибок, отмена лишних запросов, понятные состояния UI и аккуратная работа с токеном.

Отдельно проговорите границу ответственности. Axios может добавить заголовок Authorization, но не должен хранить серверные секреты в браузере. Любой ключ, который попал в клиентский JavaScript, можно увидеть. Такие секреты должны жить на сервере.

Ответ от API тоже не становится безопасным только потому, что пришел через Axios. Не рендерите внешние строки как HTML без санитайза. Если API-клиент используется в SSR, не читайте window, localStorage или cookies на уровне модуля без проверки окружения. Иначе можно получить hydration mismatch или падение на сервере.