SSR, prerender и личный кабинет
У «Маршрута» есть общедоступный каталог и будущий личный кабинет. Оба используют компоненты Svelte, однако данные имеют разную область действия. Рассмотрим три процесса: формирование HTML при запросе, подготовку HTML при сборке и оживление интерфейса в браузере. Результат урока — осмысленные настройки страниц, которые сохраняют персональные данные внутри запроса читателя.
Вы уже создали серверную загрузку урока. Она позволяет читать данные на сервере, но ещё не определяет, в какой момент будет формироваться страница. В этой главе не собираем приложение и не измеряем скорость. Приведённые настройки объясняют ожидаемый жизненный цикл SvelteKit 2; время ответа зависит от будущей среды и источников.
HTML в ответ на запрос
SSR означает серверное формирование страницы. Запрос приходит приложению, загрузка получает необходимые данные, сервер формирует HTML. Человек может увидеть содержание до завершения загрузки клиентского JavaScript. Затем браузер связывает полученную разметку с компонентами, чтобы кнопки и локальные значения начали реагировать.
Для кабинета важен текущий запрос: один читатель имеет две закладки, другой ни одной. Ответы не взаимозаменяемы. Поэтому серверное чтение личного состояния должно выполняться с учётом сессии и не превращаться в единую публичную HTML-страницу. Режим SSR не является готовой авторизацией, но даёт подходящий момент для её применения.
Оставьте SSR включённым и явно запретите prerender для личного маршрута. Полный src/routes/account/+page.ts содержит только опции, а данные позже будут поступать из соседнего +page.server.ts.
export const ssr = true;
export const prerender = false;Ожидаем, что кабинет будет обращаться к серверу за текущими данными. В корневом layout не стоит устанавливать prerender = true без исключений для дочерних личных страниц. Настройки наследуются по дереву, поэтому удобное сокращение для публичного каталога способно затронуть закрытую область.
Страница, построенная заранее
Prerender выполняет получение данных во время сборки и сохраняет результат. Такой HTML подходит публичному уроку, который одинаков для всех посетителей. Если источник каталога меняется редко, новую версию страницы можно подготовить после редакционного обновления. Это соглашение о свежести данных, а не обещание автоматически видеть каждую правку без новой сборки.
В публичном маршруте уроков можно добавить два экспорта к существующему +page.server.ts. lessons уже импортирован из фикстуры, а load продолжает искать материал по параметру.
export const prerender = true;
export function entries() {
return lessons.map(lesson => ({ id: lesson.id }));
}entries сообщает, какие значения динамического параметра должны получить страницы. Одного имени [id] недостаточно, чтобы перечислить все уроки. В реальном каталоге список должен соответствовать опубликованным материалам; в нашем примере он строится из трёх записей.
Документация page options описывает ssr, csr, prerender и функцию entries. Для «Маршрута» мы применяем эти механизмы по свойствам данных. Не следует считать, что любая страница с серверной загрузкой обязательно остаётся динамической: публичный серверный источник тоже может участвовать в подготовке HTML при сборке.
Почему нельзя заранее построить чужой кабинет
Представьте, что во время сборки есть демонстрационная сессия Алины. Если сохранить её кабинет как общий файл, следующий посетитель получит тот же набор закладок. Ошибка возникнет до исполнения браузерного кода: личные сведения уже окажутся в ответе. Скрытие блока после загрузки не исправит утечку, потому что содержание успело попасть получателю.
Обратная крайность — выключить SSR во всём приложении, рассчитывая решить проблему приватности. Тогда серверное оформление страницы исчезнет, но доступ к личному API всё равно придётся защищать. Клиентская оболочка способна запросить чужой идентификатор так же, как обычная форма. Выбор способа рендеринга не заменяет проверку владельца.
Полезно рассуждать о кэшировании отдельным вопросом. Общий каталог допускает повторное использование ответа. Личный кабинет требует политики, учитывающей авторизацию и запрет публичного общего кэша. Даже правильно настроенный SSR можно испортить неверным кэшем перед приложением. Условия размещения и заголовки войдут в договор передачи проекта, но сетевые настройки здесь не выполняются.
Браузерная интерактивность после HTML
Сервер способен вывести название и состояние формы, но не обрабатывает каждое локальное нажатие кнопки непосредственно в DOM. Для локального $state нужен браузерный компонент. Это объясняет, почему серверная страница может содержать интерактивную карточку без специального деления компонентов на отдельные категории файлов.
Если установить csr = false, клиентская интерактивность для маршрута отключится. Публичный текст может оставаться читаемым, а форма обычного POST продолжит иметь серверный путь. Локальная кнопка второго урока перестанет обновлять массив в браузере. Поэтому такую настройку нужно выбирать по содержанию страницы, а не переносить из статьи о производительности без разбора.
Ожидаемая проверка для нашего примера состоит из разных наблюдений. Публичный урок доступен по прямому адресу и содержит заголовок в исходном HTML. Кабинет выводит только историю текущей сессии. Обычная форма позже работает без клиентского улучшения. Локальные фильтры требуют JavaScript и объясняют своё состояние после его загрузки. Эти наблюдения относятся к разным механизмам, поэтому один успешный экран не подтверждает все сразу.
Свежесть и стоимость выбранного режима
Prerender переносит работу с запроса посетителя на этап сборки, но число страниц и длительность источника всё равно имеют значение. Три материала почти не влияют на процесс; тысячи записей и медленный CMS требуют отдельной стратегии. В серии не выводим показатели скорости из масштаба фикстуры и не объявляем статический режим универсально лучшим.
SSR получает актуальное состояние при запросе, однако теперь доступность репозитория влияет на ответ кабинета. Нужно предусмотреть ошибку чтения, время ожидания и честное сообщение. Мы разберём ошибки в отдельной главе, чтобы не превратить отказ хранилища в пустую историю, которая выглядела бы успешно загруженной.
К концу урока публичные страницы и кабинет имеют разные правила построения. Это постоянная архитектурная граница «Маршрута». Следующая глава добавит браузерное предпочтение оформления и покажет, как пользоваться возможностями окна, не ломая серверное создание первого HTML.