Передача Vue-проекта и границы кабинета

Оглавление серии «Vue 3: кабинет сотрудников «Команда»»

Кабинет «Команда» прошёл путь от одного компонента до маршрутов, общего источника и редактирования серверной записи с конфликтом. Последний результат серии — передача проекта с понятным договором запуска и проверки. Набор исходников ещё не равен выпущенному приложению: окружение, сервер API, сессия и подтверждение поведения остаются отдельными условиями. Зафиксируем их так, чтобы следующий разработчик мог восстановить конкретный шаг без догадок.

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

Что восстанавливает архив

Архив организован как base и последовательные полные замены lesson-NN. Сначала создают собственную папку приложения из base, затем накладывают шаги по порядку. Служебные README и snippets не являются файлами программы. Там, где урок показывает добавляемый фрагмент, состояние шага также содержит полный итоговый файл, чтобы читатель не собирал его из памяти. В lesson-14 транспорт и общий модуль уже включают соответствующие дополнения.

Ниже полный новый HANDOFF.md. Это рабочее описание учебной передачи, а не журнал выполненного выпуска.

# Передача «Команды»
Профиль: Vue 3.5.43, Router 5.4.0, Vite 8.3.4, plugin-vue 6.0.10.
Среда: Node >=22.12.0, современный браузер, same-origin сервер CONTRACT.md.
Статус: example_execution=not_run. Зависимости не установлены; lockfile не создан.
Восстановление: base -> lesson-01 -> ... -> lesson-16; полные файлы заменяются.
После самостоятельной установки: npm run dev для разработки, npm run build для файлов выпуска.
Без API состояния 12–16 не являются самостоятельным серверным кабинетом.
HTML серверной оболочки должен выдавать актуальный csrf-token текущей сессии.
Hash history сохраняет клиентский маршрут после #; это не серверный путь API.
После входа GET ограничивается доступной пользователю командой.
PATCH проверяет сессию, CSRF, право, available и version, затем сравнивает версию атомарно.
Проверяемые сценарии: первое чтение; пустая команда; ошибка; повторное чтение;
два ответа в обратном порядке; неизвестный id; 200/422/401/403/409 PATCH;
переход на другую карточку; сохранение черновика при отказе; явная замена основы.
Частные реальные данные, секреты и токены в архив не включать.
Нет SSR, серверной реализации, приглашений, удаления участников или фоновой синхронизации.

Рекомендации Vue по production deployment описывают производственную сборку. В учебном архиве команды приведены для самостоятельной подготовки и не выполнялись автором. Именно поэтому ни размер готового bundle, ни скорость рендеринга, ни результат доступа в рабочей среде не заявляются как измеренные. Можно передать исходники честно, не имитируя выпуск приложения.

Версия пакета и разрешённое дерево

Точные верхнеуровневые версии package.json делают профиль уроков однозначным. Они не фиксируют каждую транзитивную зависимость так, как это делает lockfile. После собственной установки нужно сохранить полученное разрешённое дерево и проверить его в выбранной среде. Не создавайте фиктивный package-lock вручную ради ощущения завершённости: такой файл должен отражать реальное разрешение пакетов менеджером, а его содержание не было получено в этой работе.

Номер версии Node в README обозначает нижнюю границу выбранного профиля. Он не гарантирует существование конкретного браузера, API-сервера или правильных прав файлов. Если npm-команды недоступны, сначала следует уточнить окружение, а не изменять Vue-код карточки. Разделение причин помогает не превращать любую проблему запуска в ошибку компонента. Аналогично HTTP-404 API не исправляется перестановкой RouterLink, поскольку транспорт обращается к другому ресурсу.

Для готового выпуска сервер должен отдавать правильные ресурсы и не выдавать HTML вместо JSON на /api/members. Hash history упрощает маршруты экранов, но не устраняет обработку /api. Даже если переходы внутри кабинета работают, прямое чтение API может нарушить договор из-за неверной конфигурации сервера. Передача содержит ожидаемые типы ответа, чтобы такое расхождение обнаружилось на границе, а не стало пустой коллекцией.

Доступ и видимые значения

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

CSRF-токен выдаётся с текущей сессией и отправляется в заголовке записи. Его наличие в HTML не делает пользователя администратором и не доказывает право на Анну. Сервер отдельно проверяет конкретную операцию. Ошибка 403 должна сообщать о запрете, а 401 — о необходимости входа. Для полного продукта нужны отдельные экран входа и правило завершения сессии; серия описывает интерфейс командных данных и не маскирует отсутствие этих серверных частей.

Наши имена и роли выводятся как текст. Ни ответ сервера, ни сообщение ошибки не становятся v-html. Руководство Vue по безопасности полезно сопоставлять с этим правилом при расширении карточки. Красивое оформление не требует интерпретировать произвольный пользовательский текст как программу. Если появится редактор богатого описания, он станет отдельной задачей с очисткой и собственным договором.

Проверка жизненного цикла

Передача включает ожидаемые сценарии, а не автоматизированные тесты. В собственной среде нужно увидеть, что первый отказ не показывает «участник отсутствует» как успешный вывод. После удачного чтения следующий отказ должен сохранить ранее полученные строки и показать ошибку обновления. При двух запросах в обратном порядке старый результат не должен заменить новый. Эти сценарии проверяют смысл loading, loaded и generation, а не только наличие трёх имён на странице.

Для записи отдельно проверяют сохранение черновика и основы. После 409 нельзя автоматически принять новую version и отправить прежнее намерение; кнопка замены должна явно менять форму. При неудачном чтении основы прежний снимок должен остаться. Полезный неправильный случай последней страницы — объявить проект готовым только по одному успешному PATCH. Такая проверка не рассматривает обстоятельства, ради которых были введены ожидание и конфликт.

Наконец, сравните выбранные границы с потребностями своего кабинета. Здесь нет создания реальных аккаунтов, приглашения по почте, удаления, SSR и синхронизации вкладок. Каждое расширение должно получить собственный результат и проверку прав, а не незаметно наследовать правила локального массива первых шагов. Завершённая серия передаёт понятную модель: адрес выбирает запись, общее состояние показывает подтверждённые данные, редактор хранит намерение, сервер решает право и версию. Именно эту модель следует сохранить при дальнейшем развитии проекта.

Восстановление выбранной главы

Для изучения формы можно восстановить только шаги до lesson-06 и получить локальную коллекцию без API. Для изучения конфликта требуется состояние до lesson-15 и отдельный сервер договора. Это разные учебные условия, хотя архив общий. Поэтому ссылка на исходники не должна создавать впечатление, что любую страницу достаточно открыть двойным щелчком. Сначала выбирают результат главы и её предпосылки, затем восстанавливают нужные файлы. Такая передача помогает читателю отделить недостаток окружения от ошибки собственного изменения.

Для самостоятельного воспроизведения результата «Собрать договор запуска, доступа и проверки результата» выберите lesson-16 в архиве исходников. Статус выполнения этого состояния: not_run.