Что такое гидратация

Гидратация нужна там, где страница сначала рендерится вне браузера, например на сервере, а потом должна стать обычным интерактивным приложением в браузере. Сервер отправляет HTML. Браузер показывает его пользователю. Затем загружается JavaScript, и React сопоставляет свое дерево компонентов с уже существующим DOM.

На интервью не стоит говорить, что React заново рисует всю страницу. Смысл как раз в том, что HTML уже есть. React должен понять, что этот DOM соответствует ожидаемому дереву. После этого он подключает события, состояние и дальнейшие обновления.

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

В React гидратация обычно происходит через API вроде hydrateRoot. Он работает с контейнером, где уже лежит серверная разметка. Фреймворк, например Next.js, скрывает большую часть этой механики. Но принцип остается тем же: серверный HTML должен совпасть с первым клиентским рендером.

В Next.js важно уточнить модель рендера. В Pages Router и в Client Components App Router интерактивные части проходят клиентскую гидратацию. В App Router Server Components не превращаются в клиентские компоненты с состоянием и обработчиками. Поэтому сильный ответ звучит так: гидратируются именно те части, которым нужен клиентский JavaScript.

Hydration mismatch появляется, когда сервер отдал один HTML, а клиент при первом рендере ожидает другой. Частые причины: текущее время, случайные значения, чтение localStorage, проверка window, разные данные в API или условный рендер по размеру экрана.

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

// Плохо: сервер и клиент могут увидеть разные темы на первом рендере.
function ThemeLabel() {
  const theme =
    typeof window !== "undefined"
      ? localStorage.getItem("theme") ?? "light"
      : "light";

  return <span>{theme}</span>;
}

Если у пользователя в браузере сохранена тема dark, сервер отдаст light, а первый клиентский рендер сразу захочет dark. Это и есть риск mismatch.

Более безопасный вариант: сделать первый рендер стабильным, а клиентское значение применить после гидратации. Если тема критична для первого экрана, лучше получить ее на сервере из cookie и отдать сразу правильный HTML.

// Безопаснее: первый рендер стабилен, отличие применяется после гидратации.
function ThemeLabel() {
  const [theme, setTheme] = useState("light");

  useEffect(() => {
    setTheme(localStorage.getItem("theme") ?? "light");
  }, []);

  return <span>{theme}</span>;
}

Этот вариант может дать короткий визуальный переход. Поэтому для темы сайта часто используют cookie, серверную подстановку класса на html или небольшой inline-скрипт до React, если это принято в проекте.

На интервью полезно связать определение с реальной работой. Гидратация влияет на то, как вы пишете компоненты для SSR-приложения. Все, что зависит только от браузера, нельзя бездумно использовать во время первого рендера.

Хорошее правило: первый JSX должен быть детерминированным для сервера и клиента. Если данные нужны сразу, получите их на сервере и передайте в компонент. Если данные нужны только после загрузки страницы, читайте их в эффекте и заранее продумайте fallback, чтобы UI не прыгал слишком заметно.

Еще один практический риск связан с производительностью. Большой клиентский бандл делает гидратацию долгой. Пользователь видит страницу, но не может нормально с ней работать. Поэтому в Next.js полезно оставлять больше логики в Server Components, дробить клиентские компоненты и не переносить весь экран под use client без причины.

Отдельно следите за данными. Если HTML уже содержит результат серверного запроса, клиент не должен сразу очищать экран и показывать пустой loading ради такого же запроса. Лучше передать эти данные как начальные, настроить кеш или refetch в фоне. Если запрос зависит от действий пользователя, нужна отмена или проверка актуальности, иначе поздний ответ может перезаписать новый UI.