Серверный компонент, SSR и гидратация — три разные вещи

В части II вы писали перерисовку из состояния своими руками, и вопрос был ровно один: когда перерисовать. Код жил в браузере, HTML был одним и тем же пустым каркасом, третьей сущности не существовало вовсе. App Router разбивает эту простоту на три оси, и дальше их придётся различать.

Оси независимы, и ответ на одну ничего не говорит про две другие. Клиентский компонент выполняется на сервере. Серверный компонент не гидратируется. Страница может приехать готовой разметкой, и при этом ни одного серверного компонента в ней не будет — так работал React-рендер на сервере задолго до App Router.

Слово «серверный» в первых двух вопросах значит разное: в первом — «код не уехал в браузер», во втором — «HTML посчитан до отправки». Один и тот же корень для двух разных вещей — половина всей путаницы отсюда.

Серверный рендер ничего не знает про React и гораздо старше его: сервер отдаёт готовую разметку, браузер её показывает — так работали PHP и Rails. Противоположность — пустой каркас плюс бандл: разметку считает браузер. Именно так устроен каждый пример этой части в песочнице и любой проект на Vite: createRoot получает пустой div и наполняет его.

Проверяется это без инструментов: «Просмотр кода страницы» (Ctrl+U) показывает ровно тот HTML, который приехал с сервера, а панель «Элементы» из части II — уже живое дерево, изменённое скриптами. Два разных источника правды, и путать их дорого: страница с рендером в браузере в «Элементах» выглядит точно так же, как страница с SSR.

SSR не отменяет JavaScript. Бандл всё равно загрузится и выполнится — иначе не будет ни состояния, ни обработчиков. HTML — это первый кадр; код нужен для второго и всех остальных.

Проверка на две минуты: отключите в браузере JavaScript и перезагрузите страницу. Что осталось видно — то приехало готовым. Что исчезло — то рисовал бандл.

Гидратация — операция «оживить готовое»: React обходит уже существующие узлы, строит по ним своё внутреннее дерево и вешает обработчики, вместо того чтобы создавать узлы заново. Название неудачное, но прижилось; смысл в нём один — присоединиться, а не нарисовать.

Зачем понадобилась отдельная операция, лучше всего видно на её отсутствии. Положим в страницу «серверную» разметку руками и попробуем нажать кнопку до того, как React о ней узнает.

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

// разметка, какой её прислал бы сервер: кнопка нарисована, кода за ней нет
root.innerHTML = "<button id=\"like\">Лайков: 0</button>";
const fromServer = document.getElementById("like")!;
fromServer.click();
console.log("клик до оживления:", root.textContent);

function Likes() {
  const [count, setCount] = React.useState(0);
  return (
    <button id="like" onClick={() => setCount(count + 1)}>
      {"Лайков: " + count}
    </button>
  );
}

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

setTimeout(() => {
  const alive = document.getElementById("like")!;
  console.log("узел тот же?", alive === fromServer);
  alive.click();
}, 50);
setTimeout(() => console.log("клик после оживления:", root.textContent), 150);

Первый клик не сделал ничего: обработчика в разметке нет и быть не может — onClick не превращается в атрибут HTML, это функция, а функции по проводу не ездят. Дальше интереснее: alive === fromServer даёт false. createRoot не стал разбираться в чужой разметке — он стёр её и нарисовал свою.

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

Разницу между этими двумя способами видно прямо здесь. Гидратации нужна не разметка, приехавшая по сети, а разметка, уже лежащая в контейнере — а положить её пример может и сам. Два одинаковых контейнера, два способа, один компонент:

const серверный = "<p>счёт: 0</p><button id=\"кн\">прибавить</button>";

function Счётчик() {
  const [n, задать] = React.useState(0);
  return (
    <>
      {/* одно выражение, а не текст плюс {n}: иначе React насчитает ДВА
          текстовых узла, а в разметке он один — и это уже несовпадение */}
      <p>{"счёт: " + n}</p>
      <button id="кн" onClick={() => задать(n + 1)}>прибавить</button>
    </>
  );
}

// два контейнера с одинаковой «серверной» разметкой
const стирает = document.createElement("div");
const усыновляет = document.createElement("div");
стирает.innerHTML = серверный;
усыновляет.innerHTML = серверный;
document.getElementById("root")!.append(стирает, усыновляет);

// запоминаем узлы ДО того, как React их коснулся
const былаКнопка1 = стирает.querySelector("button");
const былаКнопка2 = усыновляет.querySelector("button");

ReactDOM.createRoot(стирает).render(<Счётчик />);
ReactDOM.hydrateRoot(усыновляет, <Счётчик />);

setTimeout(() => {
  console.log("createRoot сохранил узел: ", былаКнопка1 === стирает.querySelector("button"));
  console.log("hydrateRoot сохранил узел:", былаКнопка2 === усыновляет.querySelector("button"));
  усыновляет.querySelector("button")!.click();
  setTimeout(() => console.log("после клика:", усыновляет.querySelector("p")!.textContent), 50);
}, 100);

createRoot отвечает false: он выбросил готовую кнопку и создал новую. hydrateRoot отвечает true — узел тот самый, что был в разметке, и клик после гидратации работает. Именно ради этого true серверный рендер и затевается: если бы React перерисовывал всё заново, готовый HTML не давал бы ничего, кроме картинки на долю секунды.

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

function Ticket() {
  return <p>{"Ваш номер: " + Math.random().toString(36).slice(2, 8)}</p>;
}

const root = document.getElementById("root")!;
const onServer = document.createElement("div");
const inBrowser = document.createElement("div");
root.append(onServer, inBrowser);

// два рендера одного компонента — это и есть сервер и браузер при гидратации
ReactDOM.createRoot(onServer).render(<Ticket />);
ReactDOM.createRoot(inBrowser).render(<Ticket />);

setTimeout(() => {
  console.log("сервер: ", onServer.innerHTML);
  console.log("браузер:", inBrowser.innerHTML);
  console.log("разметка совпала?", onServer.innerHTML === inBrowser.innerHTML);
}, 50);

Компонент между вызовами не менялся, а разметка разошлась. Ровно это и происходит при ошибке гидратации: React находит в DOM не то, что насчитал, пишет в консоль сообщение о несовпадении и перерисовывает поддерево на клиенте. Страница не ломается — но пользу от готового HTML на этом куске вы потеряли.

Серверный компонент отвечает на первый вопрос — где выполняется код. Он не отменяет ни серверный рендер, ни гидратацию: страница на App Router делает все три вещи сразу, просто с разными компонентами по-разному.

Четвёртая и пятая строки — самое важное в таблице. Серверный компонент попадает в HTML: его разметка приезжает вместе со всеми остальными. Но оживлять его не нужно и нечем — кода в браузере нет, состояния нет, обработчиков нет. Гидратация трогает только клиентские острова, и в этом вся экономия: чем меньше островов, тем меньше кода браузер грузит и выполняет.

В браузер от серверного компонента приезжает не код, а результат — описание готового дерева. Оно нужно React отдельно от HTML: по HTML нельзя понять, где кончается серверная разметка и начинается клиентский остров, а при переходе по Link новую страницу надо вставить в уже живое дерево, а не перезагружать целиком.

Описание можно увидеть глазами. В исходнике страницы на App Router рядом с разметкой лежат длинные строки в вызовах self.__next_f.push — это и есть дерево. Строки вида 4:I[98521,["/_next/static/chunks/…"],"ThemeToggle"] — дырки под клиентские компоненты: номер модуля, файлы, которые придётся загрузить, и имя экспорта. Всё остальное дерево приехало уже посчитанным.

Проверьте прямо здесь: Ctrl+U на этой странице и поиск по __next_f. Учебник выложен статикой, HTML посчитан заранее, а не на каждый запрос, — на форму описания это не влияет.

Читатель открыл страницу приложения на App Router. Вот что происходит и какая из трёх вещей за что отвечает.

Между четвёртым шагом и шестым есть окно, в котором страница выглядит рабочей, но не отвечает: разметка на экране, обработчиков ещё нет. Это не баг, а физика — и ровно то, что напечатал первый пример строкой «клик до оживления». Окно тем шире, чем больше кода в клиентском бандле: вот практическая причина держать границу "use client" в листьях, а не поднимать её к корню.

Одна и та же страница, собранная тремя способами, отвечает на три вопроса по-разному.

Польза от развода трёх понятий не теоретическая: она в том, что по симптому сразу видно, в какую сторону копать.

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