Предисловие

Для вашего удобства текстовый курс перенесен на отдельную платформу. Ссылка для поступления: тык

Мы настоятельно рекомендуем пользоваться именно этой платформой по ходу курса. Ссылка на текущее занятие: тык

⚠️Прежде чем переходить к заданиям - обязательно зарегистрируйтесь на курс. Иначе вас закинет на общий поток и вы не сможете взаимодействовать с сверстниками во втором модуле курса. Это не смертельно и вполне решаемо, но тем не менее.

Git, Figma, командная работа и публикация

Зачем нужна система контроля версий

Пока проект пишет один человек, его можно хранить в папке на компьютере. Проблемы начинаются, когда нужно вернуться к вчерашней версии, понять, какое изменение сломало страницу, или работать над проектом вдвоём. Появляются папки itam-board, itam-board-копия, itam-board-финал, а файлы пересылаются архивами в мессенджере.

Система контроля версий решает эти задачи. Она хранит историю изменений проекта: кто, когда и что изменил. С её помощью можно:

вернуться к любой сохранённой версии проекта;
сравнить две версии и увидеть, какие строки изменились;
работать над разными задачами параллельно и объединять результат;
работать над одним проектом вместе с другими разработчиками.

Самая распространённая система контроля версий — Git. Её используют почти во всех командах разработки, и умение работать с Git ожидают от любого разработчика.

Git — программа на вашем компьютере. Установите её с сайта git-scm.com и проверьте в терминале:

git --version

Перед первым использованием укажите имя и почту. Они будут записаны в каждое сохранённое изменение:

git config --global user.name "Анна Смирнова"
git config --global user.email "anna@example.com"

Почитать ещё

Дока: Системы контроля версий
Pro Git: О системе контроля версий

Репозиторий и коммиты

Репозиторий — папка проекта, историю которой отслеживает Git. Историю Git хранит в скрытой папке .git внутри проекта.

Коммит — сохранённое состояние проекта. У коммита есть автор, время, сообщение с описанием изменений и уникальный идентификатор.

git init
git status
git add .
git commit -m "Добавить модальное окно карточки"
git log --oneline

git init превращает текущую папку в репозиторий. Команду выполняют один раз.
git status показывает, какие файлы изменились с последнего коммита.
git add . добавляет все изменения в индекс — список изменений, которые войдут в следующий коммит. Вместо точки можно указать отдельные файлы: git add src/app/App.tsx.
git commit -m "сообщение" создаёт коммит из изменений в индексе.
git log --oneline показывает историю коммитов, по одной строке на коммит.

Обычная работа выглядит так: изменить файлы, проверить git status, добавить изменения через git add, создать коммит.

Каждый коммит стоит делать небольшим и посвящённым одной задаче. Сообщение описывает, что делает коммит: «Добавить фильтр по автору», «Исправить фокус в форме карточки». Сообщения «исправления» и «работает» через неделю ничего не скажут ни вам, ни коллегам.

Посмотреть, что изменилось в файлах до коммита, можно командой git diff.

Почитать ещё

Дока: Git
Pro Git: Запись изменений в репозиторий

Что не попадает в репозиторий

Не все файлы проекта нужно хранить в истории. Файл .gitignore в корне репозитория перечисляет файлы и папки, которые Git не отслеживает.

# .gitignore
node_modules
dist
.env.local
*.log

node_modules восстанавливается командой npm install, и в ней сотни мегабайт.
dist создаётся командой npm run build.
.env.local содержит настройки конкретного компьютера.
*.log — все файлы с расширением .log.

Шаблон Vite уже создал .gitignore с нужными записями. Проверьте, что он на месте, до первого коммита: если node_modules попадёт в историю, удалить его оттуда потом сложно.

Файл package-lock.json, наоборот, в репозиторий добавляют. Он фиксирует точные версии пакетов, чтобы у всех разработчиков установилось одно и то же.

В репозиторий никогда не добавляют пароли, ключи доступа к сервисам и другие секреты. Git хранит всю историю: даже если удалить секрет в следующем коммите, он останется в предыдущих, и любой, у кого есть доступ к репозиторию, его найдёт. Если секрет всё-таки попал в публичный репозиторий, его нужно сразу отозвать и выпустить новый.

Токен API курса открывает только учебный сервер, поэтому в проекте ITAM Board он записан в коде. Но если вы публикуете проект на GitHub, после окончания курса токен лучше сбросить на странице курса.

Почитать ещё

Pro Git: Игнорирование файлов

GitHub и удалённый репозиторий

Репозиторий на вашем компьютере называют локальным. Чтобы работать над проектом вместе с другими или просто не потерять код, копию репозитория хранят на сервере. Такую копию называют удалённым репозиторием.

Самый популярный сервис для удалённых репозиториев — GitHub. Кроме хранения кода, на нём обсуждают изменения, ведут задачи и публикуют проекты. Похожие сервисы — GitLab и Bitbucket.

Чтобы отправить проект на GitHub, создайте на сайте новый пустой репозиторий, а затем выполните в папке проекта:

git remote add origin https://github.com/anna/itam-board.git
git branch -M main
git push -u origin main

git remote add origin адрес связывает локальный репозиторий с удалённым. origin — общепринятое имя основного удалённого репозитория.
git branch -M main называет основную ветку main. Ветки разберём в следующем разделе.
git push -u origin main отправляет коммиты на сервер. Флаг -u запоминает связь, и дальше достаточно писать git push.

Для работы с удалённым репозиторием есть ещё две команды:

git pull
git clone https://github.com/anna/itam-board.git

git pull забирает с сервера коммиты, которые отправили другие, и добавляет их в локальный репозиторий.
git clone адрес скачивает репозиторий целиком в новую папку. После клонирования проекта на JavaScript выполняют npm install.

Репозиторий на GitHub — это ещё и портфолио. По нему работодатель видит, какие проекты вы делали и как пишете код.

Почитать ещё

GitHub: Hello World
Pro Git: Работа с удалёнными репозиториями

Ветки

Ветка — отдельная линия истории проекта. Изменения в одной ветке не затрагивают другие, пока ветки не объединят.

Основная ветка проекта обычно называется main. В ней лежит код, который работает и может быть опубликован. Над каждой задачей работают в отдельной ветке:

git switch -c feature/card-comments
# изменения и коммиты
git push -u origin feature/card-comments

git switch -c имя создаёт ветку и переключается на неё. В старых инструкциях для этого используют git checkout -b имя.
git switch main переключает обратно на основную ветку.
git branch показывает список веток и отмечает текущую.

Ветки позволяют:

работать над несколькими задачами одновременно и переключаться между ними;
не ломать основную ветку незаконченной работой;
показать изменения коллегам до того, как они попадут в main.

Имя ветки описывает задачу. Часто к нему добавляют приставку по типу работы: feature/ для новых возможностей, fix/ для исправлений.

Когда задача готова, ветку объединяют с main. Эта операция называется слиянием (merge). В командах слияние обычно происходит через pull request, о котором следующий раздел.

Почитать ещё

Pro Git: О ветвлении в двух словах

Pull request и код-ревью

Pull request (PR) — предложение влить изменения из одной ветки в другую, обычно в main. PR создают на GitHub после того, как ветка отправлена на сервер.

На странице PR видны все изменённые строки. Коллеги читают код, оставляют комментарии к конкретным строкам, задают вопросы и просят поправить. Автор вносит исправления новыми коммитами в ту же ветку, и они сразу появляются в PR. Когда изменения одобрены, PR сливают, и код попадает в main.

Проверка кода коллегами называется код-ревью. Ревью помогает найти ошибки до того, как они попадут к пользователям, и выровнять стиль кода в команде. Кроме того, после ревью в команде есть хотя бы два человека, которые понимают эту часть кода.

Когда вы открываете PR:

в описании напишите, что сделано и как это проверить;
делайте PR небольшими. Изменения на тысячу строк трудно внимательно прочитать, и ревью превращается в формальность;
замечания в ревью относятся к коду, а не к вам лично.

Когда вы проверяете чужой PR:

сначала смотрите на суть: правильно ли работает логика, нет ли ошибок и проблем с безопасностью, и только потом на оформление;
формулируйте замечания как предложения и объясняйте причину: «Здесь sort изменит массив в сторе, возможно, лучше toSorted?»;
отмечайте удачные решения, это тоже полезная обратная связь.

Почитать ещё

GitHub: О пулл-реквестах
Дока: Код-ревью

Конфликты слияния

Пока вы работали в своей ветке, в main могли появиться чужие изменения. Перед слиянием ветку обновляют:

git switch feature/card-comments
git pull origin main

Обычно Git объединяет изменения сам. Но если два человека изменили одни и те же строки одного файла, Git не знает, какой вариант оставить. Такая ситуация называется конфликтом слияния.

Git сообщит о конфликте и отметит спорные места в файле:

<<<<<<< HEAD
const PAGE_TITLE = 'ITAM Board'
=======
const PAGE_TITLE = 'Доска потока'
>>>>>>> main

Между <<<<<<< и ======= — версия из вашей текущей ветки.
Между ======= и >>>>>>> — версия из ветки, которую вы вливаете.

Чтобы разрешить конфликт:

Откройте файл и решите, какой вариант оставить: ваш, чужой или их объединение.
Удалите маркеры <<<<<<<, ======= и >>>>>>>.
Проверьте, что проект собирается и работает.
Добавьте файл в индекс через git add и создайте коммит.

VS Code подсвечивает конфликты и показывает над ними кнопки «Accept Current Change», «Accept Incoming Change» и «Accept Both Changes». Но решение о том, какой код правильный, всё равно принимаете вы.

Конфликтов меньше, когда ветки живут недолго, а изменения из main регулярно забирают в свою ветку.

Почитать ещё

Pro Git: Основы ветвления и слияния

Git в редакторе

Команды Git не обязательно набирать в терминале. В VS Code есть вкладка Source Control: она открывается значком с ветвящейся линией на левой панели или сочетанием Ctrl+Shift+G.

На вкладке Source Control можно:

увидеть список изменённых файлов и открыть сравнение старой и новой версии;
добавить файл в индекс кнопкой «+» рядом с ним;
написать сообщение и создать коммит;
отправить коммиты на сервер и забрать чужие кнопкой синхронизации;
переключить ветку через название ветки в левом нижнем углу окна.

Для работы с GitHub есть отдельная программа GitHub Desktop с похожими возможностями.

Графические инструменты удобны для повседневной работы, особенно для просмотра изменений перед коммитом. Но команды в терминале всё равно стоит знать. Они одинаково работают в любой среде, в том числе на сервере без графического интерфейса, а в документации и ответах на вопросы решения описывают именно командами.

Полезная привычка перед каждым коммитом — посмотреть на список изменений. Так в коммит не попадут временные console.log, отладочные изменения и лишние файлы.

Почитать ещё

VS Code: Source Control (англ.)

Figma: как устроен макет

Figma — сервис, в котором дизайнеры рисуют интерфейсы. Фронтенд-разработчик получает от дизайнера ссылку на макет и переводит его в код. Figma работает в браузере, и для просмотра макета достаточно ссылки.

Макет в Figma состоит из слоёв. Список слоёв находится на левой панели и выглядит как дерево, похожее на DOM. Основной вид слоя — фрейм: прямоугольная область, внутри которой лежат другие слои. Экран приложения, карточка, кнопка — всё это фреймы, вложенные друг в друга.

Когда вы изучаете макет, задача не в том, чтобы перенести на страницу каждый пиксель. Нужно понять структуру:

из каких частей состоит экран, и какие из них повторяются;
какие компоненты уже есть в проекте, а какие нужно создать;
какие значения цветов, размеров шрифта и отступов используются во всём макете;
как интерфейс выглядит в разных состояниях и на экранах разной ширины.

Хороший макет устроен похоже на React-приложение: повторяющиеся элементы сделаны компонентами, цвета и отступы вынесены в переменные, а экраны собраны из этих элементов. Чем аккуратнее макет, тем проще перенести его структуру в код.

Потренироваться в чтении макетов можно на файлах из раздела Community в Figma: там опубликованы тысячи бесплатных макетов интерфейсов.

Почитать ещё

Figma: Основы Figma (англ.)

Auto layout, компоненты и варианты

Многие понятия Figma напрямую соответствуют понятиям фронтенда.

В Figma	В коде
Фрейм с Auto layout	Контейнер с `display: flex`, `gap` и `padding`
Компонент	React-компонент
Экземпляр компонента	Место в разметке, где компонент используется
Варианты компонента: Primary и Secondary, Default и Hover	Проп `variant` и состояния `:hover`, `:focus`, `:disabled`
Свойства компонента	Пропсы компонента
Переменные и стили цветов, шрифтов, отступов	CSS-переменные в `:root`
Constraints	Поведение элемента при изменении ширины родителя

Auto layout — режим фрейма, в котором дочерние слои выстраиваются автоматически в строку или столбец с заданным расстоянием и отступами. Если дизайнер использовал Auto layout, направление, отступы и выравнивание можно перенести в Flexbox почти без изменений.

Компонент в Figma — элемент, который используется во многих местах макета. Изменение компонента меняет все его экземпляры. Если в макете кнопка сделана компонентом с вариантами, в коде ей соответствует компонент Button с пропом variant.

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

:root {
  --color-primary: #4f46e5;
  --color-text: #1f2328;
  --radius-card: 12px;
  --space-m: 16px;
}

.card {
  padding: var(--space-m);
  border-radius: var(--radius-card);
  color: var(--color-text);
}

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

Почитать ещё

Figma: Auto layout, Компоненты (англ.)
Дока: Кастомные свойства

Как брать значения из макета

Чтобы узнать размеры, цвета и отступы элемента, выделите слой в макете. Свойства выбранного слоя показаны на правой панели: размеры, цвет заливки, параметры шрифта, скругление, тень.

У Figma есть режим для разработчиков Dev Mode. Он включается переключателем в верхней панели и показывает свойства слоя в виде, привычном разработчику: с отступами до соседних элементов, названиями переменных и фрагментами CSS. Dev Mode доступен не на всех тарифах Figma. Если его нет, те же значения можно найти на правой панели и измерить расстояния, наведя курсор на соседний слой с зажатой клавишей Alt (на Mac — Option).

Фрагменты CSS из Dev Mode не стоит копировать в проект целиком. В них абсолютные размеры и позиции, которые подходят только для одной ширины экрана, и они не учитывают структуру ваших компонентов. Берите из макета значения: цвета, размеры шрифтов, отступы, скругления, и записывайте их в свои стили и переменные.

Картинки и иконки выгружают из макета через раздел Export в нижней части правой панели:

иконки и логотипы — в формате SVG. Такой файл весит мало и остаётся чётким при любом размере;
фотографии и сложные изображения — в PNG или WebP. Для экранов с высокой плотностью пикселей их выгружают в двойном размере, 2x.

Если в макете используется шрифт, проверьте, что его можно подключить к сайту, например через Google Fonts, и что его лицензия это разрешает.

Почитать ещё

Figma: Dev Mode, Экспорт (англ.)

Что уточнить у дизайнера

Макет почти никогда не отвечает на все вопросы. Обычно в нём нарисован интерфейс, в котором всё загрузилось, данных ровно столько, сколько нужно, и нет ошибок. Прежде чем начинать вёрстку, пройдите по списку и уточните то, чего в макете нет.

Состояния элементов. Как выглядит кнопка при наведении, в фокусе и в выключенном состоянии? Как выглядит поле с ошибкой? Как выглядит выбранная карточка?
Загрузка. Что показывать, пока данные загружаются?
Пустые состояния. Как выглядит колонка без карточек? Страница пользователя, у которого нет карточек?
Ошибки. Что показать, если сервер не ответил или данные не удалось сохранить?
Ширина экрана. Как интерфейс выглядит на телефоне шириной 375 пикселей и на мониторе шириной 1920? Где колонки переносятся или начинают прокручиваться?
Длинный и неудобный контент. Что будет с заголовком в три строки, с именем из тридцати символов, с картинкой неожиданных пропорций, с карточкой без картинки?

В ITAM Board индикаторы загрузки, пустые колонки и сообщения об ошибках — именно те состояния, которых обычно нет в макетах. Если не спросить о них заранее, их придётся придумывать в последний момент, и они будут выглядеть чужеродно.

Задавайте вопросы до начала работы, а договорённости записывайте в комментариях к макету или в описании задачи. Так их найдут и дизайнер, и другие разработчики.

Почитать ещё

Figma: Комментарии в файлах (англ.)

API как контракт

Фронтенд и бэкенд часто пишут одновременно разные люди. Чтобы в конце всё сошлось, до начала работы договариваются о контракте API: какие будут эндпоинты, какие поля в запросах и ответах, какие ошибки.

Удобный порядок работы над новой возможностью:

Обсудить, какие данные нужны экрану и какие действия выполняет пользователь.
Записать контракт в виде описания OpenAPI. Описание может подготовить бэкенд-разработчик, или его составляют вместе.
Пока бэкенд не готов, фронтенд работает на моках в форме будущего ответа, как мы делали на девятом занятии.
Когда бэкенд готов, фронтенд генерирует типы из описания и заменяет моки настоящими запросами. Если что-то разошлось с договорённостью, TypeScript покажет ошибки.

Если контракт нужно изменить, сначала меняют описание API и предупреждают всех, кто им пользуется. Незаметное переименование поля на сервере ломает фронтенд у пользователей, а поиск причины занимает часы.

Иногда фронтенду нужны данные, которых нет в API, или ответ устроен неудобно для интерфейса. В этом случае обсуждайте изменение с бэкенд-разработчиком, а не собирайте нужные данные десятком запросов на клиенте. Хорошее API проектируют с учётом того, как им будут пользоваться.

Почитать ещё

Что такое OpenAPI (англ.)

Документация проекта

Документация отвечает на вопросы, которые иначе пришлось бы задавать людям. В проекте фронтенда её обычно три вида.

README — файл README.md в корне репозитория. Он объясняет, что это за проект, как его запустить и как он устроен. Посмотрите на README ITAM Board: в нём адрес API, требования к Node.js, команды запуска, описание возможностей и структура папок. Если новому человеку в команде для запуска проекта нужно что-то объяснять устно, README устарел.

README пишут в формате Markdown: заголовки начинаются с #, списки — с -, код оформляют обратными кавычками. GitHub показывает README на главной странице репозитория.

Комментарии в коде объясняют, почему код написан именно так. Что делает строка, обычно видно из самого кода, а причина решения — нет. Хороший комментарий: «Флаг ignore отбрасывает ответ, если пользователь успел открыть другую карточку». Бесполезный комментарий: «Устанавливаем ignore в true».

Описание задачи содержит критерии готовности: как понять, что задача сделана. Не «сделать фильтры», а «поиск по заголовку и описанию, три варианта сортировки, переключатель „Только мои“, фильтры сохраняются при переходе между страницами». Если критериев нет, уточните их до начала работы, иначе представление о готовой задаче у вас и у заказчика может не совпасть.

Договорённости записывают туда, где их найдут: в описание API, в README, в описание задачи или в комментарий к макету. Решение, которое осталось в личной переписке, для остальной команды не существует.

Почитать ещё

Дока: Markdown

Как задавать вопросы

Задавать вопросы — нормальная часть работы. Но от формулировки вопроса зависит, как быстро на него ответят.

Вопрос, на который сложно ответить:

Не работает шапка, помогите.

Вопрос, на который ответят за минуту:

Хочу, чтобы после сохранения профиля в шапке сразу обновлялось имя. Сохранение работает: в Network видно ответ 200 с новым именем, а me в сторе обновляется, я проверил через useAuthStore.getState(). Но шапка показывает старое имя, пока не обновишь страницу. В шапке имя читается так: const me = useAuthStore.getState().me. Что может быть не так?

В хорошем вопросе есть:

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

Пока вы формулируете вопрос так подробно, часть вопросов решается сама: вы проверяете очевидные причины и замечаете ошибку. В примере выше ответ — компонент читает стор через getState() во время рендера и не подписан на изменения. Нужен хук с селектором.

Перед тем как спросить, поищите ответ в документации библиотеки и в сообщении об ошибке целиком. А после того как проблема решена, напишите, в чём было дело: следующий человек с тем же вопросом найдёт ответ.

Почитать ещё

Stack Overflow: Как задать хороший вопрос

Сборка приложения для публикации

Пока приложение запущено командой npm run dev, оно доступно только на вашем компьютере. Публикация (деплой) — размещение приложения на сервере, откуда его может открыть любой пользователь.

Приложение на Vite перед публикацией собирают:

npm run build
npm run preview

npm run build проверяет типы и собирает приложение в папку dist.
npm run preview запускает локальный сервер для собранной версии. Перед публикацией стоит проверить, что приложение работает именно в собранном виде.

В папке dist оказываются index.html, файлы JavaScript и CSS и картинки:

dist/
├── index.html
├── favicon.svg
└── assets/
    ├── index-DkR3a9Qz.js
    └── index-B7xLm2Pc.css

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

Собранное SPA — это статические файлы. Для их публикации не нужен Node.js или другой сервер с кодом: файлы из dist может раздавать любой статический хостинг.

Почитать ещё

Vite: сборка для продакшена (англ.)

Где разместить приложение

Для публикации статических сайтов есть сервисы с бесплатными тарифами, которых достаточно для учебного проекта.

Vercel и Netlify подключаются к репозиторию на GitHub. После каждого git push в основную ветку сервис сам выполняет npm install и npm run build и публикует содержимое dist. Сайт получает адрес вида itam-board.vercel.app или itam-board.netlify.app с HTTPS. Для веток с pull request сервисы создают отдельные предварительные версии сайта, и изменения можно посмотреть до слияния.

Чтобы опубликовать проект на Vercel или Netlify:

Отправьте проект на GitHub.
Зарегистрируйтесь в сервисе через аккаунт GitHub.
Создайте новый проект и выберите репозиторий.
Сервис определит, что проект собирается Vite. Проверьте, что команда сборки — npm run build, а папка результата — dist.

GitHub Pages публикует статические файлы прямо из репозитория на GitHub. Сайт получает адрес вида anna.github.io/itam-board/. Потому что приложение открывается не из корня адреса, а из папки /itam-board/, в vite.config.ts нужно указать base: '/itam-board/', а в BrowserRouter — basename="/itam-board".

Какой бы хостинг вы ни выбрали, проекту на React Router нужна ещё одна настройка. О ней следующий раздел.

Почитать ещё

Vite: публикация статического сайта (англ.)
Vercel: Vite, Netlify: Vite (англ.)

Настройка SPA на хостинге

На одиннадцатом занятии мы разобрали, что у SPA один файл index.html, а адресов много. Если пользователь откроет ссылку https://itam-board.vercel.app/cards/42 или обновит страницу на этом адресе, хостинг начнёт искать файл cards/42, не найдёт его и ответит 404.

Хостинг нужно настроить так, чтобы на любой адрес, для которого нет файла, он отдавал index.html. Дальше React Router сам покажет нужную страницу.

Vercel. В корне проекта создайте файл vercel.json:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Netlify. В папке public создайте файл _redirects. Vite скопирует его в dist при сборке:

/*    /index.html   200

GitHub Pages. Такой настройки нет. Обычно после сборки копируют index.html в файл 404.html: GitHub Pages показывает его для несуществующих адресов, и приложение загружается.

Ошибка с этой настройкой коварна: если открыть сайт с главной страницы и переходить по ссылкам, всё работает, потому что переходы выполняет React Router. Проблема проявляется только при открытии прямой ссылки или обновлении страницы. Поэтому после публикации обязательно откройте в новой вкладке адрес внутренней страницы, например страницы пользователя.

Почитать ещё

Vercel: rewrites (англ.)
Netlify: redirects и rewrites (англ.)

Переменные окружения и проверка перед публикацией

Значения, которые отличаются на вашем компьютере и на хостинге, передают через переменные окружения. Файл .env.local в репозиторий не попадает, поэтому на хостинге переменные задают в настройках проекта. В Vercel и Netlify для этого есть раздел Environment Variables.

Vite подставляет значения переменных с приставкой VITE_ в код во время сборки. Поэтому после изменения переменной на хостинге проект нужно пересобрать. И всё, что начинается с VITE_, окажется в файлах JavaScript, которые получает пользователь. Секретные ключи, которые должны знать только сервер, так передавать нельзя.

Перед публикацией и после неё пройдите по списку:

npm run build проходит без ошибок и предупреждений;
npm run preview показывает работающее приложение, включая прямые ссылки на внутренние страницы;
адрес API указывает на настоящий сервер, а не на localhost;
на хостинге настроена выдача index.html для всех адресов;
node_modules, dist и .env.local не попали в репозиторий;
после публикации во вкладке Network запросы к API возвращают ответы без ошибок CORS и 401;
в консоли опубликованной версии нет ошибок.

Опубликованное приложение со ссылкой в README — самый наглядный способ показать проект: его можно открыть и проверить, не устанавливая ничего на компьютер.

Почитать ещё

Vite: переменные окружения и режимы (англ.)

Что дальше

ITAM Board, который вы написали за второй модуль, — настоящее приложение: оно работает с сервером, разделено на слои, проверяет данные и обрабатывает ошибки. Доска вашего потока продолжит работать и после окончания курса.

Технологии фронтенда быстро меняются, но подходы, которые мы использовали, остаются: интерфейс как результат состояния, иммутабельные данные, одна функция на один запрос, типы как описание данных, понятные сообщения об ошибках. С ними проще освоить любую новую библиотеку.

Не пытайтесь изучить всё сразу. Выберите одно направление на ближайший месяц:

Тестирование. Vitest и React Testing Library позволяют проверять функции и компоненты автоматически. Начните с теста для filterCards.
Доступность. Пройдите по своему приложению только с клавиатуры и попробуйте программу экранного доступа. Начните со введения в доступность от W3C.
Загрузка данных. Библиотека TanStack Query кэширует ответы сервера, повторяет запросы и обновляет данные в фоне. Многое из того, что мы писали в сторе вручную, она делает сама.
Производительность. Profiler, разделение кода через lazy, метрики Core Web Vitals.
Серверный рендеринг. Next.js или React Router в режиме фреймворка строят страницы на сервере. Это нужно, когда страницы должны быстро открываться и хорошо индексироваться поисковиками.
TypeScript. Условные типы, satisfies, строгие настройки компилятора.
CSS. Контейнерные запросы, :has(), анимации, Tailwind CSS как другой подход к стилям.

Лучше всего навыки закрепляет собственный проект, которым вы будете пользоваться сами: трекер привычек, каталог настольных игр, расписание для своей команды. В нём обязательно встретятся задачи, которых не было в курсе, и их решение научит больше, чем ещё один учебник.

Читайте документацию: react.dev, Доку, MDN. Открывайте код библиотек, которыми пользуетесь. Задавайте вопросы и отвечайте на чужие.

Спасибо, что прошли курс до конца.

К списку уроков

Предисловие

Git, Figma, командная работа и публикация

Зачем нужна система контроля версий

Почитать ещё

Репозиторий и коммиты

Почитать ещё

Что не попадает в репозиторий

Почитать ещё

GitHub и удалённый репозиторий

Почитать ещё

Ветки

Почитать ещё

Pull request и код-ревью

Почитать ещё

Конфликты слияния

Почитать ещё

Git в редакторе

Почитать ещё

Figma: как устроен макет

Почитать ещё

Auto layout, компоненты и варианты

Почитать ещё

Как брать значения из макета

Почитать ещё

Что уточнить у дизайнера

Почитать ещё

API как контракт

Почитать ещё

Документация проекта

Почитать ещё

Как задавать вопросы

Почитать ещё

Сборка приложения для публикации

Почитать ещё

Где разместить приложение

Почитать ещё

Настройка SPA на хостинге

Почитать ещё

Переменные окружения и проверка перед публикацией

Почитать ещё

Что дальше

Почитать ещё