Чем пользоваться для выполнения запросов нескольких Promise

На интервью лучше не отвечать одним словом "Promise.all". Надежнее показать, что вы выбираете комбинатор под поведение данных и интерфейса.

Promise.all нужен, когда операции можно стартовать параллельно и нужен полный набор успешных результатов. Promise.allSettled нужен, когда ошибку одного запроса нельзя превращать в полный отказ всего экрана. Promise.race и Promise.any нужны для сценариев с первым завершившимся или первым успешным результатом.

Практический вывод простой. Сначала объясните контракт данных, потом назовите метод. Так ответ звучит не как заученное API, а как инженерное решение для UI.

Хорошая формулировка ответа может звучать так:

Если все запросы независимы и экрану нужны все данные, я запущу их параллельно через Promise.all. Если часть данных можно показать независимо, выберу Promise.allSettled и отдельно обработаю успешные и упавшие результаты. Если запросы зависят друг от друга, буду выполнять их последовательно.

Такая формулировка закрывает главный риск вопроса. Не все наборы Promise нужно выполнять одинаково. Иногда параллельность ускоряет экран, иногда ломает порядок, а иногда скрывает частично успешные данные.

Для независимых запросов, без которых экран нельзя показать, подойдет Promise.all.

async function loadPageData() {
  try {
    const [profileResponse, settingsResponse, permissionsResponse] = await Promise.all([
      fetch("/api/profile"),
      fetch("/api/settings"),
      fetch("/api/permissions"),
    ]);

    if (!profileResponse.ok || !settingsResponse.ok || !permissionsResponse.ok) {
      throw new Error("Failed to load page data");
    }

    const [profile, settings, permissions] = await Promise.all([
      profileResponse.json(),
      settingsResponse.json(),
      permissionsResponse.json(),
    ]);

    return { profile, settings, permissions };
  } catch (error) {
    // Показать общий error state или retry, потому что экран зависит от всех данных.
    throw error;
  }
}

Важно помнить, что fetch сам по себе не считает HTTP 404 или 500 rejected. Он обычно успешно возвращает Response, поэтому статус нужно проверить отдельно через response.ok. Иначе можно получить успешный промис с ошибочным HTTP-ответом и сломать дальнейший парсинг или UI.

Если данные независимы, не всегда стоит валить весь экран из-за одной ошибки. Например, рекомендации могут не загрузиться, но профиль пользователя и список заказов все равно можно показать.

async function requestJson(url) {
  const response = await fetch(url);

  if (!response.ok) {
    throw new Error(`Request failed: ${url}`);
  }

  return response.json();
}

async function loadDashboard() {
  const results = await Promise.allSettled([
    requestJson("/api/profile"),
    requestJson("/api/orders"),
    requestJson("/api/recommendations"),
  ]);

  return results.map((result) => {
    if (result.status === "fulfilled") {
      return { status: "success", data: result.value };
    }

    return { status: "error", error: result.reason };
  });
}

Здесь вы явно сохраняете информацию по каждому запросу. Проверка response.ok важна и в этом варианте тоже. Без нее HTTP 500 может попасть в UI как успешный результат. Это полезно для UI с частичным успехом, но вам все равно нужно продумать состояние каждого блока: загрузка, данные, ошибка и retry.

Если следующий запрос зависит от предыдущего, параллельный запуск через Promise.all будет ошибкой. Например, нельзя оплатить заказ до того, как сервер вернул его orderId.

Плохой вариант:

// Плохо: payment не знает orderId в момент запуска.
await Promise.all([
  createOrder(cart),
  payForOrder(orderId),
]);

Безопаснее выполнить шаги явно:

const order = await createOrder(cart);
const payment = await payForOrder(order.id);
const status = await loadOrderStatus(order.id);

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

Главный риск не в синтаксисе, а в поведении интерфейса. Если запустить слишком много запросов одновременно, можно получить rate limit, долгую очередь в браузере, резкие скачки loading state и тяжелую обработку ответов на главном потоке.

Если компонент может размонтироваться или пользователь быстро меняет фильтры, подумайте об отмене устаревших запросов. Для fetch это делают через AbortController. Иначе старый ответ может прийти позже нового и перезаписать актуальные данные.

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

  Promise.all([
    fetch(`/api/products?query=${query}`, { signal: controller.signal }),
    fetch(`/api/facets?query=${query}`, { signal: controller.signal }),
  ])
    .then(([productsResponse, facetsResponse]) => {
      if (!productsResponse.ok || !facetsResponse.ok) {
        throw new Error("Failed to load search data");
      }

      return Promise.all([productsResponse.json(), facetsResponse.json()]);
    })
    .then(([products, facets]) => {
      setProducts(products);
      setFacets(facets);
    })
    .catch((error) => {
      if (error.name !== "AbortError") {
        setError(error);
      }
    });

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

Без cleanup старый запрос может обновить состояние после нового поиска. В React это дает race condition. Пользователь видит результаты не для текущего фильтра. Отмена не заменяет обработку ошибок, но убирает лишнюю сетевую работу и защищает UI от устаревшего ответа.