Запросы в эффектах: гонки, водопады и зачем знать базовый вариант

Честная база: эффект, параметр, три состояния

Запрос в эффекте — это синхронизация: «пока компонент показывает запрос q, на экране должен быть ответ сервера для q». Эффект перезапускается при каждом изменении query, и вы вручную пишете три состояния, нужные любому UI данных, — загрузку, ошибку, данные:

function FlightSearch({ query }) {
  const [results, setResults] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    let ignore = false;                    // защита от гонки
    const controller = new AbortController(); // отмена на сети
    setLoading(true);
    setError(null);

    fetch(`/api/flights?q=${encodeURIComponent(query)}`, {
      signal: controller.signal,
    })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => {
        if (!ignore) { setResults(data); setLoading(false); }
      })
      .catch((err) => {
        if (err.name === "AbortError") return; // ожидаемо при cleanup
        if (!ignore) { setError(err); setLoading(false); }
      });

    return () => {            // выполняется перед перезапуском и при размонтировании
      ignore = true;
      controller.abort();
    };
  }, [query]);
  // рендер loading / error / results...
}

Это примерно двадцать строк на эндпоинт, и каждая строка заслужила своё место. Форма, которую стоит усвоить: тело эффекта запускает запрос, привязанный к одному значению query; cleanup отрекается от него. React гарантирует: cleanup выполняется перед следующим телом эффекта и при размонтировании — на этом порядке держится вся корректность.

Гонка: ответы приходят не в том порядке, в каком вы их послали

Наберите быстро «w», «wa», «war» — и вы выпустили три запроса. HTTP не гарантирует порядок между запросами: кеши, ретраи и нагрузка на сервер переставляют их свободно. Без защиты каждый ответ вызывает setResults, и последним рисуется самый медленный запрос. Две защиты делают разную работу. Флаг ignore — это корректность: переменная замыкания на каждый запуск эффекта; когда cleanup её переключает, setResults устаревшего замыкания становится no-op. Ответ всё равно скачивается — вы просто отказываетесь его коммитить. AbortController — это эффективность: он отменяет саму сетевую работу, освобождая слоты соединений браузера на источник (HTTP/1.1 даёт 6) и время сервера. Одного abort почти хватает — отклонённый promise выходит через AbortError, — но флаг ignore защищает ещё и неотменяемую асинхронную работу после fetch (уже запущенный res.json(), цепочку трансформаций), поэтому идиома — пара. StrictMode прогоняет setup→cleanup→setup при dev-монтировании ровно затем, чтобы доказать: ваш cleanup действительно отрекается от первого запроса. Если в dev видны двойные коммиты — продакшен-гонка реальна.

Водопады: дерево компонентов становится расписанием сети

Вторая структурная проблема невидима внутри отдельного компонента. ProfilePage запрашивает пользователя, рендерит <Posts userId={...}> только когда пользователь пришёл, а Posts запрашивает посты и рендерит <Comments>, который запрашивает снова. Каждый fetch стартует только после того, как данные родителя приземлились и ребёнок смонтировался, — три логически независимых запроса идут последовательно. При 200 мс на круг это 600 мс чистой задержки, навязанной структурой, ещё до серверного времени; на LTE с RTT 75 мс и TLS-рукопожатием реальные трейсы регулярно показывают водопады в 1,5–2 с на страницах, которые могли бы загрузиться за один круг. Сигнатура в network-панели безошибочна: лесенка. Дерево решило ваше расписание, а дерево ничего не знает о сети. Лекарства по нарастающей амбициозности: поднять запросы в самый верхний компонент, знающий все параметры, и запустить их через Promise.all; стартовать запросы до рендера (в лоадере роута или обработчике события) и передавать promise вниз; либо отдать проблему библиотеке или фреймворку, чей кеш разделяет «кто это рендерит» и «кто это запрашивает». Последний ход — тема остатка этого юнита.