Данные прямо в компоненте: await вместо useEffect

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

type Task = { id: number; title: string };

// сети в песочнице нет, но задержка ведёт себя так же: ответ приходит не сразу
function loadTasks(): Promise<Task[]> {
  return new Promise((resolve) =>
    setTimeout(() => resolve([{ id: 1, title: "Купить хлеб" }]), 60)
  );
}

const root = document.getElementById("root")!;

function TasksPage() {
  const [tasks, setTasks] = React.useState<Task[] | null>(null);
  React.useEffect(() => {
    let alive = true; // уборка против гонки ответов — из главы про эффекты
    void loadTasks().then((data) => {
      // ответ пришёл — заглядываем на страницу до того, как обновим состояние
      console.log("на странице в этот момент:", root.textContent);
      if (alive) setTasks(data);
    });
    return () => {
      alive = false;
    };
  }, []);
  console.log("рендер, задач:", tasks === null ? "ещё нет" : tasks.length);
  if (tasks === null) return <p>Загрузка…</p>;
  return (
    <ul>
      {tasks.map((task) => (
        <li key={task.id}>{task.title}</li>
      ))}
    </ul>
  );
}

ReactDOM.createRoot(root).render(<TasksPage />);

Дорога тут длиннее, чем кажется по коду. Сервер отдал разметку, браузер скачал и разобрал бандл, React смонтировал дерево, эффект отработал — и вот теперь ушёл запрос за данными. Данные всё это время лежали на сервере: чтобы их попросить, пришлось сперва доставить в браузер программу, которая умеет просить.

Ветки «грузится», «ошибка», «готово» заводились не от любви к состояниям, а потому что ответ приходит позже кадра. Убери отставание — и описывать станет нечего.

Серверный компонент выполняется там, где данные уже лежат: рядом с базой, файлами и внутренними сервисами. Просить их через сеть ему не у кого — ему нужно только дождаться ответа. А ждать функция умеет с части I.

type Task = { id: number; title: string; done: boolean };

// в проекте это импорт из lib/tasks.ts, где лежит доступ к базе;
// здесь объявление без тела: важна форма вызова, а не заглушка
declare function loadTasks(): Promise<Task[]>;

// app/tasks/page.tsx (в файле перед именем стоит export default)
async function TasksPage() {
  const tasks = await loadTasks();
  return (
    <ul>
      {tasks.map((task) => (
        <li key={task.id}>{task.title}</li>
      ))}
    </ul>
  );
}

Ни useState, ни useEffect, ни флага alive. От компонентов первой главы этот отличается ровно одним словом — async. Возвращается разметка, уже собранная с данными, и в браузер едет она, а не программа, которая эти данные добудет.

Что при этом делает сервер, видно, если проделать его работу руками. Компонент — обычная функция; асинхронная функция возвращает промис; сервер зовёт функцию и ждёт промис, прежде чем превращать элемент в текст.

type Task = { id: number; title: string };

function loadTasks(): Promise<Task[]> {
  return new Promise((resolve) =>
    setTimeout(() => resolve([{ id: 1, title: "Купить хлеб" }]), 30)
  );
}

async function TasksPage() {
  const tasks = await loadTasks();
  return (
    <ul>
      {tasks.map((task) => (
        <li key={task.id}>{task.title}</li>
      ))}
    </ul>
  );
}

// сервер обращается с компонентом как с обычной функцией: зовёт и ждёт ответа
void (async () => {
  const pending = TasksPage();
  console.log(pending instanceof Promise);
  const element = await pending;
  console.log(element.type);
  console.log(element.props.children.length);
})();

TasksPage() вернул не элемент, а обещание элемента — и до await с ним нельзя сделать ничего полезного. В этом и разница между двумя мирами: браузеру ждать некогда, он обязан немедленно нарисовать хоть что-то, а сервер собирает ответ и вправе подождать.

async function Hello() {
  return <p>Привет</p>;
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Hello />);

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

// заглушки вместо запросов: отвечают своим именем через заданное время
const load = (name: string, ms: number): Promise<string> =>
  new Promise((resolve) => setTimeout(() => resolve(name), ms));

// округляем до сотен: точная миллисекунда зависит от машины, а порядок — нет
const round = (ms: number): number => Math.round(ms / 100) * 100;

void (async () => {
  const t1 = Date.now();
  const user = await load("Рико", 100);
  const posts = await load("посты", 100);
  console.log(user, posts, round(Date.now() - t1));

  const t2 = Date.now();
  const both = await Promise.all([load("Рико", 100), load("посты", 100)]);
  console.log(both[0], both[1], round(Date.now() - t2));
})();

Двести против ста. Два await подряд выстраивают запросы в очередь, и страница ждёт их сумму, а не самый долгий из них. С тремя запросами по 100 мс разница будет уже втрое.

Лечится это не хитрым приёмом, а вопросом «зависит ли второй запрос от первого». Если нет — вызовы разводят с ожиданием: запустить оба сразу, а await поставить там, где значение действительно понадобилось.

const load = (name: string, ms: number): Promise<string> =>
  new Promise((resolve) => setTimeout(() => resolve(name), ms));

void (async () => {
  const t = Date.now();
  const userPromise = load("Рико", 100);
  const postsPromise = load("посты", 100);

  const user = await userPromise;
  const posts = await postsPromise;
  console.log(user, posts, Math.round((Date.now() - t) / 100) * 100);
})();

Promise.all из части I и эта форма делают одно и то же — работа стартует в момент вызова, а не в момент await. Выбор между ними чисто вкусовой: Promise.all короче, отдельные промисы читаются лучше, когда ответы нужны в разных местах разметки.

Только помните про отказ: у Promise.all первая же ошибка роняет всё. Когда часть данных необязательна, берут allSettled — или ловят ошибку внутри своей загрузки.

Второй вид водопада — по дереву: родитель ждёт свои данные, отрисовывается, и только тогда ребёнок начинает свой запрос. Соседние ветви сервер обходит параллельно, а вложенность неизбежно выстраивает цепочку. Тут Promise.all не поможет — помогает другое: отпустить медленную ветку ждать отдельно, не задерживая остальную страницу. Об этом следующая статья главы.

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

type User = { id: number; name: string };

let trips = 0; // сколько раз мы на самом деле сходили в базу

async function loadUser(id: number): Promise<User> {
  trips += 1;
  return { id, name: "Рико" };
}

// та же карта, что заводит cache(): ключ — аргумент, значение — начатый промис
function once(fn: (id: number) => Promise<User>) {
  const started = new Map<number, Promise<User>>();
  return (id: number): Promise<User> => {
    const known = started.get(id);
    if (known) return known;
    const fresh = fn(id);
    started.set(id, fresh);
    return fresh;
  };
}

const getUser = once(loadUser);

void (async () => {
  // так выглядят два независимых компонента, которым нужен один и тот же автор
  const [inHeader, inCard] = await Promise.all([getUser(1), getUser(1)]);
  console.log(trips, inHeader === inCard);
})();

Ключ в том, что в карту кладётся не результат, а начатый промис. Второй вызов приходит, когда первый ещё в пути, — и получает ту же самую работу, а не запускает свою. Именно поэтому оба компонента получили один объект: inHeader === inCard оказалось true.

Ровно это делает cache() из React — своими руками карту писать не нужно.

type User = { id: number; name: string };

declare function selectUser(id: number): Promise<User>;

// lib/user.ts — в проекте это import { cache } from "react";
// обернули один раз, дальше зовут откуда угодно и сколько угодно
const getUser = React.cache((id: number) => selectUser(id));

console.log(typeof getUser);

Карту заводит только серверная сборка React. В браузерной — той, что стоит в песочнице, — cache() пропускает вызов насквозь, поэтому пример выше и написан руками.

У fetch в Next такое поведение встроено: два одинаковых GET в одном проходе рендера уйдут по сети один раз. Для базы, файлов и клиентов чужих сервисов оборачивайте сами.

Живёт эта карта ровно один ответ сервера: два посетителя — две карты, и ничего лишнего друг другу они не покажут. Кеш, который переживает запрос, — совсем другая машина и отдельная глава про кеширование.

await в компоненте бросает исключение так же, как везде. Необработанное улетит в ближайший error.tsx — файл из главы про App Router. Если же ошибка ожидаемая и страница без этих данных имеет смысл, её ловят на месте.

type Rate = { usd: number };

declare function loadRate(): Promise<Rate>;

async function UsdRate() {
  try {
    const rate = await loadRate();
    return <span>{rate.usd} ₽</span>;
  } catch {
    // курс не критичен для страницы: прочерк лучше, чем экран ошибки вместо всего
    return <span>—</span>;
  }
}

Отдельный случай — «данные есть, но их нет»: запрос отработал и вернул null. Это не ошибка, а честный ответ, и для него в Next есть notFound().

type Task = { id: number; title: string };

declare function loadTask(id: string): Promise<Task | null>;
// в проекте: import { notFound } from "next/navigation"
declare function notFound(): never;

async function TaskPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params; // params — промис, статья «Динамические сегменты и асинхронные params»
  const task = await loadTask(id);
  if (!task) notFound();
  return <h1>{task.title}</h1>;
}

И главное ограничение: пока компонент ждёт, ждёт и ответ. Быстрым запросам это только на пользу — кадра с «загрузкой» не будет вовсе. А медленный отчёт задержит собой всю страницу, и посетитель проведёт это время на пустой вкладке. Лечится это не возвращением к useEffect, а тем, что страницу начинают отдавать частями: loading.tsx из главы про App Router и границы Suspense внутри неё. Об этом — следующая статья.

Обратите внимание на последнюю строку: это не «старый способ и новый». Данные, которые зависят от действий пользователя уже на странице, по-прежнему грузит клиентская половина — и делает это через use(), Suspense или обычный эффект. Меняется другое: первая порция данных, та, ради которой открыли адрес, больше не требует круга по сети.