«Нужен сайт на Nuxt» звучит как готовое задание. Но пока непонятно, кто будет менять цены, как посетитель попадёт в кабинет и что произойдёт, если система учёта не ответит. В Гуси-Лебеди мы советуем сначала разобрать эти сценарии. Тогда выбор технологии можно объяснить задачами проекта, а результат разработки проверить без спора о том, насколько сайт «современный».
Nuxt, или Nuxt.js, это открытый фреймворк на основе Vue для сайтов и веб-приложений. Vue помогает создавать интерфейс, а Nuxt добавляет организацию страниц, получение данных, серверные обработчики и сборку приложения. В статье рассматриваем Nuxt 4 по актуальной официальной документации. Примеры ниже условные: это способ обсуждать проект, а не описание выполненного нами заказа.
Когда Nuxt помогает проекту, а когда усложняет его
Представим магазин с публичным каталогом и кабинетом покупателя. Карточку товара открывают из поиска или по ссылке. В кабинете человек смотрит только свои заказы. Менеджер меняет описание через систему управления контентом, а цены и остатки приходят из системы учёта. Здесь уже есть несколько разных задач, которые нельзя решить одним обещанием «включим SSR».
Nuxt уместно рассматривать, когда команде нужен интерфейс на Vue вместе с организацией маршрутов, серверным формированием страниц или обработчиками API. Фреймворк создаёт маршруты по файлам, предусматривает автоматические импорты и работу с TypeScript. Но он не становится системой учёта или редактором текстов: эти части нужно выбрать и связать с приложением.
Полезный вопрос на встрече с разработчиком: «Что именно нам даёт Nuxt в этом задании?» Хороший ответ связывает возможности с поведением сайта. Например, содержимое публичной карточки должно присутствовать в серверном HTML, а закрытые данные заказа выдаются после проверки пользователя. Ответ «это популярный фреймворк» ничего не говорит о результате.
Если задача сводится к небольшому виджету на существующем сайте, отдельный Nuxt-проект может добавить ненужную сборку и поддержку. Если нужен обычный контентный сайт, стоит сравнить решение с подходящей CMS: кто редактирует страницы, как выпускаются изменения, какая команда продолжит работу. Это сравнение условий конкретного проекта, а не рейтинг технологий.
До выбора стека мы рекомендуем описать одну важную пользовательскую цепочку целиком: посетитель находит товар, выбирает вариант, отправляет заявку и получает понятное подтверждение. Для разработки сайта на Nuxt.js такое описание полезнее перечня модулей: становится ясно, какие данные и интеграции действительно понадобятся.
Как связать адреса страниц с их содержимым
В Nuxt 4 страницы по умолчанию располагаются в app/pages/. Файл app/pages/catalog/[slug].vue задаёт динамический маршрут карточки, где slug обозначает часть адреса. Это помогает организовать код, но не определяет, какие товары существуют и что показывать по неизвестной ссылке. Правила адресов и ответы приложения всё равно нужно согласовать.
Для условного магазина составим небольшую карту. Это не готовая конфигурация: режим выбирают с учётом обновления данных, персонализации и площадки размещения.
| Раздел | Что согласовать до разработки |
|---|---|
| Статья или страница о компании | Можно ли сформировать HTML при сборке и кто запустит обновление после правки текста |
| Каталог и карточка товара | Откуда приходят данные, допустимы ли устаревшие цены и как обновляется сохранённый ответ |
| Кабинет покупателя | Кто имеет доступ, как истекает сессия и как исключить выдачу чужих данных |
| Удалённая карточка | Должна ли ссылка вернуть 404 или перенаправить на действительно подходящую страницу |
Nuxt позволяет задавать правила для групп адресов через routeRules: предварительно формировать страницы, менять режим рендеринга или стратегию кэширования. Документация по режимам рендеринга отдельно отмечает, что гибридный режим недоступен при nuxt generate. Поэтому фраза «часть сайта статическая, часть серверная» должна сопровождаться решением о сборке и размещении.
У кэша есть понятная бизнес-сторона. Если карточка хранится некоторое время, нужно определить, какую цену посетитель видит и какую система проверит перед оформлением. Нельзя назначать всем страницам одинаковый срок хранения только потому, что такой пример встретился в руководстве. Для персональных ответов отдельно проектируют условия доступа и хранения.
Маршрут проверяют двумя способами: переходом внутри сайта и прямым открытием адреса в новой вкладке. Добавьте обновление страницы, неверный параметр и отсутствующий товар. Красивое меню не доказывает, что сохранённая ссылка работает правильно. Руководство по маршрутизации описывает файловые маршруты и их проверку; принципы серверного рендеринга мы разбираем отдельно. Здесь важнее связать выбранный режим с конкретной страницей.
Как получать данные и не путать страницу с действием
Загрузить описание товара и отправить заказ: это разные операции. Первую выполняют, чтобы показать страницу. Вторую запускает человек, и у неё есть результат в системе. При обсуждении API полезно держать это различие перед глазами.
useFetch- Подходит для получения данных страницы по URL с учётом серверного рендеринга.
useAsyncData- Позволяет обернуть другую асинхронную логику, например запрос через библиотеку системы управления контентом.
$fetch- Выполняет запрос. В обработчике пользовательского действия его можно использовать, например, для отправки формы.
Согласно документации по получению данных, прямой вызов $fetch в настройке компонента при универсальном рендеринге может выполниться на сервере и повториться в браузере при гидратации. useFetch и useAsyncData передают серверный результат клиенту через payload. Это решает задачу первоначальной загрузки, но само по себе не защищает заказ от повторной отправки.
Допустим, покупатель нажал кнопку, ответ задержался, и он нажал снова. В задании нужно описать состояние ожидания, сообщение об ошибке и правила повторной операции. Если важна защита от дубля, её согласуют и на сервере. Просто заблокировать кнопку недостаточно для всех способов повторить запрос.
Серверная часть Nuxt работает на Nitro и может размещать обработчики рядом с интерфейсом. В server/api/ располагают API приложения, а действующий backend может оставаться отдельной системой. Руководство по серверной части описывает эти возможности. До реализации определите, где проверяются данные, хранятся заказы и фиксируется успешное действие.
Закрытая страница и защищённое API: это тоже разные вещи. Middleware маршрутов относится к Vue-части приложения и не выполняется для серверных адресов вроде /api/*. Редирект на вход не заменяет проверку прав в обработчике. Для кабинета это удобно проверять на тестовых пользователях: один не должен получить заказ другого по прямому запросу к API.
При разработке серверной логики и интеграций полезно согласовать не только успешный ответ. Нужны отсутствие товара, неверные данные, отказ внешней системы и истёкшая сессия. Читателю интерфейса должно быть ясно, что случилось и какое действие доступно дальше.
Что проверить перед запуском и передать на поддержку
Демо на компьютере разработчика ещё не показывает, как проект работает после размещения. Принимать нужно согласованную сборку в среде, близкой к рабочей, с тестовыми данными и теми же типами интеграций. Заранее запишите ожидаемые результаты, чтобы проверка не свелась к просмотру главной страницы.
- Открытие по ссылке. Карточка доступна напрямую и после обновления вкладки. Несуществующий адрес получает согласованный ответ, а не пустой экран с кодом 200.
- Обновление содержимого. Изменение описания или цены проходит через предусмотренный процесс. Проверяющий понимает, когда обновится HTML или кэш и где проверить результат.
- Доступ к кабинету. Проверены вход, выход, окончание сессии и права тестовых пользователей. Ограничения действуют и при обращении к API.
- Отправка формы. Проверены ожидание, ошибка, повтор и фактическая запись результата в принимающей системе. Сообщение «отправлено» соответствует успешной операции.
- Выпуск и возврат предыдущей версии. Другой участник команды может собрать проект по инструкции и выполнить согласованный порядок отката.
Способ размещения выбирают под сборку. По документации Nuxt, результат предварительной генерации не включает работающий сервер для собственных обработчиков. Если форме нужен серверный API, это должно быть отдельной частью архитектуры или серверной сборкой, а не неожиданностью после загрузки статических файлов на хостинг.
На поддержку передают репозиторий, зафиксированные версии зависимостей, инструкции сборки и размещения, перечень переменных окружения без секретов, описание интеграций и порядок обновления модулей. Доступы передают через согласованный защищённый канал. Важно понимать не только где лежат файлы, но и кто отвечает за данные, инфраструктуру и выпуск изменений.
Если цель включает скорость, договоритесь о страницах, устройстве, условиях и показателях измерения. Если важна доступность для поиска, проверьте серверный HTML, метаданные, ссылки и ответы адресов. Само наличие Nuxt не является результатом этих проверок. Хорошо подготовленный проект отличается тем, что команда может объяснить каждое решение и воспроизвести его работу, а заказчик понимает, что именно принимает.