Серверный компонент: код, который не уехал в браузер

Положите файл app/page.tsx в проект Next.js, напишите в нём обычный компонент — без директив, без настроек, без единого нового слова — и он выполнится на сервере. Не «может выполниться», не «выполнится, если попросить»: сервер — это состояние по умолчанию для всего, что лежит в app. Серверным компонент делает место, а не отметка в коде.

// app/page.tsx — ни директив, ни настроек: этот компонент серверный.
export default function HomePage() {
  const tasks = ["Купить хлеб", "Позвонить маме"];
  console.log("собираю страницу, задач:", tasks.length);
  return (
    <ul>
      {tasks.map((task) => (
        <li key={task}>{task}</li>
      ))}
    </ul>
  );
}

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

Первое, что сбивает с толку на живом проекте, — именно эта строчка с console.log. В консоли браузера её нет. Она печатается в терминале, где вы запустили next dev, вперемешку с логами запросов, — потому что компонент выполнился там же, где и всё остальное серверное. В проде такая строка уйдёт в логи сервера, и увидит её не посетитель, а тот, у кого есть доступ к машине.

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

function Where() {
  // window существует только в браузере: в Node такого имени нет вовсе,
  // поэтому typeof — самый короткий способ узнать место выполнения
  const place = typeof window === "undefined" ? "сервер" : "браузер";
  console.log("выполнено на месте:", place);
  return <p>Выполнено на месте: {place}</p>;
}

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

Из «компонент выполнился на сервере» следует главное: его код не попадает в бандл. Не «минифицируется получше», не «грузится попозже» — его там нет. Вместе с ним не едет и всё, чем он пользовался: разбор Markdown, подсветка кода, форматирование дат, драйвер базы.

Посчитаем один экран блога. Сколько килобайт из него доедет до телефона посетителя?

type Module = { name: string; where: "server" | "client"; kb: number };

// один экран блога: страница, драйвер базы, разбор Markdown и кнопка «нравится»
const project: Module[] = [
  { name: "app/post/page.tsx", where: "server", kb: 3 },
  { name: "lib/db.ts", where: "server", kb: 42 },
  { name: "lib/markdown.ts", where: "server", kb: 180 },
  { name: "components/like-button.tsx", where: "client", kb: 2 }
];

const weight = (list: Module[]) => list.reduce((sum, m) => sum + m.kb, 0);
const shipped = project.filter((m) => m.where === "client");

console.log(weight(project));
console.log(weight(shipped));
console.log(shipped.map((m) => m.name));

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

Если код не уехал, то что уехало? Результат вызова. Сервер обращается с компонентом как с обычной функцией: вызывает, получает элемент React — тот самый обычный объект из статьи «JSX — это не HTML» — и превращает его в текст, который можно передать по сети.

Проделаем это руками. В компоненте ниже есть внутренняя переменная и обработчик клика; посмотрите на код и решите, что из этого окажется в отправленном тексте.

function Price() {
  const markup = 1.4; // наценка: цифра для нас, а не для покупателя
  return (
    <button onClick={() => console.log("в корзину")}>
      Купить за {Math.round(1000 * markup)} ₽
    </button>
  );
}

// сервер вызывает компонент как обычную функцию и получает описание разметки,
// а по сети едет уже текст — вот он
const payload = JSON.stringify(Price().props);

console.log(payload);
console.log(payload.includes("markup"), payload.includes("onClick"));

Осталось число 1400 и два куска текста. Переменной markup в отправленном нет, потому что после вызова функции её не существует — она была нужна ровно на одно умножение. А onClick исчез тише: JSON.stringify молча выбрасывает свойства-функции. Функцию нельзя записать текстом так, чтобы на другой стороне она ожила.

Настоящий формат, которым Next передаёт результат, богаче JSON — он умеет и ссылки на клиентские компоненты, и куски, которые приедут позже. Но суть та же: по проводу идут данные. Отсюда весь список того, чего серверный компонент «не умеет», — и это не запреты, придуманные авторами, а следствия одного факта.

Компилятор про всё это молчит, и к такому вы не привыкли. Вот файл, в котором с точки зрения TypeScript безупречно всё.

// app/page.tsx — типы сходятся, JSX верный, диагностик ноль.
// А сборка Next на этом файле остановится.
import { useState } from "react";

export default function LikeButton() {
  const [likes, setLikes] = useState(0);
  return (
    <button onClick={() => setLikes(likes + 1)}>
      Нравится: {likes}
    </button>
  );
}

Ноль диагностик — и это правда так: ошибка здесь не в типах, а в месте. Файл лежит в app без отметки, значит серверный, а useState и onClick в серверном компоненте невозможны по причинам из таблицы выше. Next остановит сборку и прямо предложит поставить 'use client'. Как ставится эта отметка и почему она расползается на соседние файлы — следующая статья главы.

«Типы сошлись, а работать не будет» — новый для вас класс ошибок. Место выполнения компилятор не проверяет: для него это просто функция. Проверяет его сборка.

Пока компонент выполнялся в браузере, дорога к данным была длинной: компонент отправлял fetch("/api/tasks"), на другом конце стоял ваш обработчик, он шёл в базу и возвращал JSON, компонент раскладывал ответ по состояниям «грузится / ошибка / готово». Половина этой дороги существовала ровно затем, чтобы браузер мог спросить у сервера то, что сервер и так знал.

Серверный компонент стоит на том же конце провода, что и база. Спрашивать через посредника ему не у кого.

// app/tasks/page.tsx — обычный компонент. Особенное в нём одно: место.
// Он выполняется на сервере, поэтому ходить в базу можно прямо отсюда.
// В lib/db.ts лежат пул соединений и пароль — в браузер этот модуль не поедет.
import { db } from "@/lib/db";

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

export default async function TasksPage() {
  const tasks: Task[] = await db.query("select id, title, done from tasks order by id");
  return (
    <ul>
      {tasks.map((task) => (
        <li key={task.id}>{task.title}</li>
      ))}
    </ul>
  );
}

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

И то же самое объясняет вторую половину выгоды — что осталось дома. Строка подключения, пароль от базы, ключ платёжного API, чтение файла с диска, внутренний адрес соседнего сервиса: всё это код серверного компонента, а его в браузере нет.

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

type UserRow = { id: number; name: string; email: string; passwordHash: string };

// строка из базы: селект написали через звёздочку, как пишут в спешке
const row: UserRow = {
  id: 1,
  name: "Рико",
  email: "rico@example.com",
  passwordHash: "$2b$10$Nx7q"
};

// «отдам объект целиком, компонент возьмёт нужное» — и вот что уедет
const payload = JSON.stringify({ user: row });
console.log(payload.includes("passwordHash"));

// а нужно было выбрать поля руками
const safe = JSON.stringify({ user: { id: row.id, name: row.name } });
console.log(safe);

Открывая незнакомый файл в app, теперь смотрят не на содержимое, а на первую строку. Её отсутствие — это тоже ответ.

// components/like-button.tsx — отметка стоит первой строкой файла,
// до импортов и до любого другого кода
"use client";

import { useState } from "react";

export default function LikeButton() {
  const [likes, setLikes] = useState(0);
  return (
    <button onClick={() => setLikes(likes + 1)}>
      Нравится: {likes}
    </button>
  );
}

Без этой строки — сервер. С ней — браузер, и тогда возвращается всё, что вы знаете из этой части: состояние, обработчики, эффекты, ссылки на узлы. Вместе с ними возвращается и вес в бандле, поэтому строка не бесплатная.

Границу между колонками проводите вы, и проводить её выгодно как можно ниже по дереву. Пометить 'use client' страницу целиком технически можно — но тогда в браузер уедет и список, и текст, и всё, что вы старательно оставляли на сервере, ради одной кнопки внизу. Куда именно ставить отметку и почему она задевает больше файлов, чем кажется, — тема следующей статьи.

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