Выбрали React для сайта, а разработчик предлагает добавить Next.js. Что изменится для посетителя, редактора и человека, который будет поддерживать проект? В Гуси-Лебеди мы начинаем с этих вопросов: они помогают обсудить реальную работу сайта, а не только название технологии.
Next.js представляет собой фреймворк для веб-приложений на React. React отвечает за компоненты интерфейса; Next.js добавляет средства организации страниц, серверной работы и выпуска приложения. Это не выбор «Next.js или React»: в таком проекте они работают вместе. Разберём, где Next.js может пригодиться, на условном примере сайта с записью на приём.
Когда сайту на React нужен Next.js
Представим сайт, где человек выбирает услугу, специалиста и свободное время. Описание услуги открыто всем, расписание приходит из системы записи, а отменить приём может только его владелец. За одним экраном скрываются разные задачи: показать понятную страницу, получить актуальные данные и выполнить защищённую операцию.
Next.js имеет смысл оценивать, когда команда хочет организовать эти части в рамках React-приложения. Но сам по себе интерактивный календарь ещё не обосновывает смену платформы. Возможно, на существующем сайте достаточно подключить готовую систему записи. А возможно, требуется отдельный интерфейс с собственными сценариями и интеграциями. Сначала сравниваем эти варианты, затем выбираем инструмент.
Для обсуждения разработки интерфейса на React полезнее принести схему действий посетителя, чем пожелание «сделайте на современном фреймворке». На схеме должны быть видны источник расписания, способ входа, изменение записи и поведение при ошибке. Так становится понятно, какой объём работы действительно нужен.
Ещё одно уточнение для действующего сайта: какой роутер используется? В документации Next.js выделены App Router и Pages Router. Ниже мы разбираем подход App Router. Инструкцию для другого устройства проекта нельзя переносить без проверки, даже если название фреймворка совпадает.
Что остаётся на сервере, а что работает в браузере
В App Router страницы и шаблоны по умолчанию являются серверными компонентами. Для состояния интерфейса, обработчиков нажатий и возможностей браузера нужны клиентские компоненты. Именно такую границу описывает руководство по Server и Client Components.
На нашем условном сайте сервер может получить описание услуги и подготовить данные для страницы. В браузере посетитель переключает даты и выбирает время. Поэтому интерактивный календарь удобно обсуждать как отдельную часть: ему нужны выбранная дата, обработчики и понятное состояние загрузки. Делать весь сайт клиентским только ради этой функции необязательно.
Есть нюанс, который легко потерять за терминами. Клиентский компонент не означает, что при первом открытии он совсем не участвует в подготовке HTML на сервере. Next.js может заранее сформировать HTML, а затем браузер подключает интерактивность. Поэтому фраза «всё отрисовывается у клиента» требует уточнения. Если сравниваете способы показа страницы, начните с разбора серверного рендеринга, а затем спросите, как это устроено на конкретном маршруте.
Разделение компонентов также не заменяет проверку прав. Допустим, посетитель нажал «Отменить запись». Сервер должен проверить, имеет ли он право отменять именно эту запись. Скрытая кнопка или проверка в браузере не решают эту задачу. Для Server Functions официальное руководство по изменению данных отдельно требует проверки авторизации и прав на операцию.
Мы предлагаем проверять границу на простом вопросе: что произойдёт, если запрос поступит напрямую, без экрана с кнопкой? Ответ должен опираться на серверную обработку, а не на то, что интерфейс «не позволяет так нажать».
Почему после изменения расписания сайт может показывать старые данные
Администратор убрал время из расписания, но посетитель всё ещё видит его свободным. Это условный сценарий для проверки, а не история о выполненном нами проекте. Одна из возможных причин связана с переиспользованием сохранённого результата: данные уже изменились в источнике, а сайт ещё показывает предыдущую версию. Чтобы установить причину в реальном приложении, нужно проследить получение и обновление данных.
Кэш помогает не выполнять одну и ту же работу заново. Но срок пригодности результата зависит от его смысла. Описание услуги и наличие свободного времени нельзя автоматически считать одинаково свежими. Для расписания важен момент повторной проверки, особенно перед подтверждением записи.
Актуальное руководство по кэшированию рассматривает режим Cache Components, который включают настройкой cacheComponents: true. Для приложения без этого режима документация отсылает к другой модели. Поэтому мы не советуем переносить случайный пример из старой статьи: сначала уточните версию Next.js и используемую конфигурацию.
В задании лучше написать конкретное правило: «После изменения расписания новые посетители получают обновлённый список, а при подтверждении записи сервер повторно проверяет доступность времени». Затем команда определяет, каким способом получить нужное поведение. Само обновление экрана не защищает от ситуации, когда два человека выбрали одно время: окончательное решение должно принимать место, где хранится и изменяется запись.
Проверка должна включать уже открытое окно. Откройте расписание, измените доступность в источнике и вернитесь к выбору времени без полного перезапуска сайта. Посмотрите, когда обновляется список и что происходит при попытке подтвердить устаревший вариант. Сообщение должно объяснять следующий шаг, например предложить выбрать другое время. Требовать от человека самостоятельно разбираться с «ошибкой кэша» не нужно.
Как выбрать размещение для функций приложения
Размещение выбирают вместе с устройством проекта. По официальной документации по развёртыванию Next.js поддерживает запуск на Node.js, в Docker, статический экспорт и адаптеры для других платформ. У этих вариантов разные возможности.
| Вариант | Что учесть до запуска |
|---|---|
| Сервер Node.js | Нужна среда для работающего приложения, его сборки и запуска. В документации заявлена поддержка всех возможностей Next.js. |
| Docker | Приложение запускается в контейнере. Помимо кода нужно согласовать окружение и порядок обновления контейнера. |
| Статический экспорт | Подходит для размещения подготовленных файлов. Серверные функции Next.js в этом варианте недоступны. |
| Адаптер платформы | Совместимость зависит от адаптера. Нужно проверить поддержку функций, используемых в проекте. |
Вернёмся к записи на приём. Если её обработка выполняется серверной функцией Next.js, одного хостинга статических файлов недостаточно. Если же браузер обращается к отдельному сервису записи, архитектура будет другой. Эти варианты нужно различать до покупки размещения и передачи доступа, а не после обнаружения неработающей кнопки.
Для серверной части и интеграций отдельно согласуйте переменные окружения, хранение секретов и поведение при недоступности внешней системы. Посетителю нужен понятный ответ; команде поддержки нужны данные для поиска ошибки. Показать пустой календарь при сбое и показать отсутствие свободного времени не одно и то же.
Что проверить перед приёмкой Next.js-проекта
Просмотр главной страницы подтверждает только её показ. Мы советуем принимать рабочий сценарий целиком на сборке, размещённой в согласованном окружении. Для нашего примера удобен следующий порядок.
- Путь нового посетителя.
- Откройте страницу услуги по прямой ссылке, затем пройдите к расписанию через меню. Проверьте описание, выбор даты и возврат назад. Эти два способа входа не должны оставлять человека с пустым экраном или потерянным выбором без объяснения.
- Запись и изменение данных.
- Подтвердите выбранное время, проверьте результат в системе записи и попробуйте отменить его с разрешённой ролью. Затем повторите попытку с пользователем без нужных прав. Ожидаемый результат каждого действия заранее запишите в задании.
- Сбой и восстановление.
- В тестовом окружении воспроизведите недоступность источника расписания. Проверьте сообщение, повторную попытку и сохранение введённых данных там, где это предусмотрено сценарием. Отдельно пройдите проверку устаревшего времени из предыдущего раздела.
Поисковую доступность проверяйте на публичных страницах, которые должны находиться в поиске: адрес, содержимое, заголовок и настройки доступа. Личный кабинет не нужно делать публичным ради этой проверки. А скорость оценивайте на фактических страницах и устройствах: название Next.js само по себе не подтверждает ни быстрый интерфейс, ни позиции в Яндексе.
При передаче проекта попросите зафиксировать версии зависимостей, роутер, команды сборки и запуска, схему интеграций и способ безопасного обновления. Если обновление не прошло проверку, у ответственного должен быть понятный порядок восстановления рабочей версии. Эти сведения пригодятся и новой команде, и тем, кто будет сопровождать сайт дальше.
Для нас хороший результат выглядит просто: посетитель записывается без лишних препятствий, администратор понимает, откуда берётся расписание, а команда умеет проверить и выпустить изменение. Когда эти условия описаны, обсуждать Next.js становится гораздо легче.