Подключаем внешний API

Запрос к чужому серверу в современном браузере выглядит короче, чем кажется: const res = await fetch(url) — и у нас есть ответ. Но ответ — это ещё не данные. fetch завершается, как только пришли заголовки: статус известен, а тело может продолжать загружаться. Поэтому за первым await почти всегда следует второй: const data = await res.json().

В песочнице учебника сети нет, поэтому дальше вместо fetch будет заглушка с тем же интерфейсом — объект с ok, status и методом json(). Функция, написанная на такой заглушке, без единой правки работает и с настоящим fetch: важна форма ответа, а не то, кто его выдал.

async function load(request) {
  const res = await request; // здесь был бы fetch(url)
  const data = await res.json();
  console.log(data.temp);
}
load(Promise.resolve({ ok: true, json: () => Promise.resolve({ temp: 34 }) }));

Всё, что попало в код страницы, видно пользователю. Ключ платного API, вшитый во фронтенд, — это уже утёкший ключ: браузер должен ходить на ваш собственный сервер, а тот — на чужой API.

Про то, что 404 — не ошибка, вы уже знаете: fetch не считает ошибкой ни 404, ни 500, потому что с его точки зрения запрос удался — сервер ответил, ответ доставлен. Промис отклоняется только тогда, когда ответа не было вовсе: нет сети, сорвалось соединение, запрос отменили. Поэтому try/catch вокруг fetch ловит меньше, чем вы думаете.

Лечится это одной строкой: проверить res.ok (он true для статусов 200–299) и превратить плохой статус в исключение самому. Дальше по коду будет ровно один путь для всех бед — catch.

async function loadTemp(res) {
  if (!res.ok) throw new Error("HTTP " + res.status);
  const data = await res.json();
  return data.temp;
}
loadTemp({ ok: false, status: 503 }).catch((err) => console.log(err.message));

Пока идёт запрос, у экрана нет данных — и это нормальное, а не аварийное состояние. Удобно держать в приложении одно поле status с тремя значениями: loading, error, ready. Тогда разметка становится честной функцией от состояния, а не набором разбросанных флагов вроде isLoading и hasError, которые рано или поздно окажутся включены одновременно.

Правило простое: перед запросом ставим loading, в try получаем данные и ставим ready, в catch — error с текстом. Ни одна ветка не остаётся без записи состояния, иначе спиннер останется крутиться навсегда.

function view(state) {
  if (state.status === "loading") return "Загружаем…";
  if (state.status === "error") return "Ошибка: " + state.error;
  return "Температура: " + state.data.temp;
}
console.log(view({ status: "loading" }));
console.log(view({ status: "error", error: "нет сети" }));
console.log(view({ status: "ready", data: { temp: 34 } }));

Отмену запроса вы видели в статье про fetch; в проекте она из удобства становится обязательной — ниже видно, почему. Устройство напомним: создаём const controller = new AbortController(), кладём controller.signal в настройки запроса, второй аргумент fetch — fetch(url, { signal: controller.signal }) — и в любой момент зовём controller.abort(). Промис запроса тут же отклонится ошибкой с именем AbortError.

const controller = new AbortController();
controller.signal.addEventListener("abort", () => console.log("прервали"));
console.log(controller.signal.aborted);
controller.abort();
console.log(controller.signal.aborted);

Важная деталь: отмена приходит в тот же catch, что и настоящие сбои. Но пользователю нечего показывать — он сам ушёл со страницы или начал новый поиск. Поэтому в обработчике ошибку по имени отделяют от остальных и молча выходят.

function report(err) {
  if (err.name === "AbortError") return "отмена — молчим";
  return "показать ошибку: " + err.message;
}
console.log(report({ name: "AbortError", message: "aborted" }));
console.log(report({ name: "TypeError", message: "Failed to fetch" }));

Пользователь печатает в поиске «Дуб», потом «Дубай». Уходят два запроса, и никто не обещал, что ответы вернутся в том же порядке: первый мог застрять в пути и прийти вторым. Экран покажет результаты по «Дуб», хотя в поле написано «Дубай». Ошибки нет, данные настоящие — просто устаревшие.

Два лекарства, и они дополняют друг друга. Первое — AbortController: перед новым запросом отменить предыдущий, чтобы он не тратил сеть. Второе — сторож на стороне кода: нумеровать запросы и применять только ответ с последним номером. Второе нужно даже с отменой, потому что ответ мог уже прилететь в момент отмены.

let lastId = 0;
function apply(id, text) {
  if (id !== lastId) return "устаревший ответ отброшен";
  return "показываем: " + text;
}
lastId = 2; // отправлен второй запрос
console.log(apply(1, "Дуб"));
console.log(apply(2, "Дубай"));

У fetch нет таймаута по умолчанию: запрос может висеть, пока браузер не сдастся сам. Ставьте предел явно — AbortSignal.timeout(5000) отменит запрос через пять секунд. Попадёте вы в тот же catch, что и при отмене, но имя у ошибки другое — TimeoutError, а не AbortError: молчать про таймаут как про отмену нельзя, человек ничего не отменял. Пять секунд молчания для пользователя — уже вечность, лучше показать ему повтор.

Если у приложения есть чем прикрыться — прошлые данные, кеш, разумные значения по умолчанию — покажите их, но честно пометьте как устаревшие. Пустой экран хуже старой цифры с подписью «данные могли устареть».

async function withCache(load, cached) {
  try {
    return await load();
  } catch {
    return { ...cached, stale: true }; // сеть подвела — отдаём последнее известное
  }
}
withCache(() => Promise.reject(new Error("offline")), { temp: 30 }).then((d) => console.log(d.temp, d.stale));

function delayMs(attempt) {
  return 500 * 2 ** attempt;
}
console.log(delayMs(0), delayMs(1), delayMs(2));