gorbenko.pavel
dea024f3a9
build-and-deploy / prepare (push) Successful in 0s
build-and-deploy / build-and-push (., Dockerfile, hr-appeals-web) (push) Successful in 8s
Tests / frontend-test (push) Successful in 11s
build-and-deploy / build-and-push (server, server/Dockerfile, hr-appeals-auth) (push) Successful in 4s
build-and-deploy / deploy (push) Successful in 15s
Co-authored-by: Mariya Trishina <trishina.mariya@tnsu.kz> Reviewed-on: http://git.tnsu.kz/gorbenko.pavel/hr-appeals/pulls/2
96 lines
5.2 KiB
Markdown
96 lines
5.2 KiB
Markdown
# hr-appeals
|
|
|
|
Форма обращений сотрудников в HR департамент.
|
|
|
|
Заменяет встроенную Microsoft Forms: даёт собственный интерфейс в фирменном стиле
|
|
(общие токены и компоненты, что и `request-portal`) без чужого брендинга и служебных
|
|
плашек в подвале.
|
|
|
|
## Стек
|
|
|
|
- React 17 + TypeScript (строгий режим)
|
|
- Vite 6
|
|
- SCSS Modules
|
|
- [`@tnsu/ui-kit`](http://git.tnsu.kz/timur.gorodetskiy/tnsu-ui-kit) — общие UI-компоненты
|
|
- Vitest — тесты бизнес-логики
|
|
|
|
React именно 17-й: `@tnsu/ui-kit` объявляет его в `peerDependencies`.
|
|
|
|
## Запуск
|
|
|
|
Пакеты `@tnsu/*` лежат в приватном реестре — он прописан в `.npmrc`, отдельная
|
|
настройка не нужна, но нужен доступ к `git.tnsu.kz`.
|
|
|
|
```bash
|
|
npm install
|
|
npm run dev
|
|
```
|
|
|
|
`npm run dev` поднимает сразу оба процесса: фронтенд на `:3000` и сервис
|
|
авторизации `hr-appeals-auth` на `:3100` (логи помечены `[web]` и `[auth]`).
|
|
Форма отправляется на `/api/feedback`, dev-сервер проксирует это на `:3100` —
|
|
так же, как nginx в проде (`nginx.conf`). Без запущенного `[auth]` отправка
|
|
формы отдаёт 500 от прокси.
|
|
|
|
Сервису нужны две вещи: `server/.env` (скопируйте
|
|
[server/.env.example](server/.env.example)) и сертификат Azure AD в каталоге
|
|
[`secrets/`](secrets/README.md). Сами `.pem`-файлы в git не хранятся — их надо
|
|
взять у администратора. Подробнее — в [server/README.md](server/README.md).
|
|
|
|
Прочие команды:
|
|
|
|
```bash
|
|
npm run dev:web # только фронтенд, без сервиса авторизации
|
|
npm run build # проверка типов + тесты + production-сборка в dist/
|
|
npm run typecheck # только проверка типов
|
|
npm run test # тесты один раз (то же, что гоняет CI)
|
|
npm run test:watch # тесты в режиме наблюдения при разработке
|
|
npm run preview # просмотр собранной версии
|
|
```
|
|
|
|
## Тесты и CI
|
|
|
|
Покрыты чистые функции бизнес-логики — `validateFeedback` и `getAppealFieldsConfig`
|
|
(`*.test.ts` рядом с тестируемым модулем). React-компоненты не тестируются: сначала
|
|
нужно решить, куда форма отправляет данные (см. «Что не сделано»), тестировать UI до
|
|
этого — тесты, которые придётся сразу переписывать.
|
|
|
|
`.gitea/workflows/test.yml` гоняет `npm run ci` (проверка типов + Vitest) на каждый
|
|
push в `main` и на каждый PR — тот же принцип, что в `request-portal`, но без Jest/Heft
|
|
(там их привязка к SPFx, нам он не нужен) и без шага деплоя: куда и как разворачивать
|
|
собранный `dist/`, ещё не решено.
|
|
|
|
## Структура
|
|
|
|
```
|
|
src/
|
|
components/ переиспользуемые UI-обёртки
|
|
Field/ FormField из ui-kit + текст ошибки валидации
|
|
PageShell/ шапка страницы и центрированный контент
|
|
features/feedback/ собственно форма обращения
|
|
model.ts типы данных, справочники, пустое состояние
|
|
model.test.ts
|
|
texts.ts все пользовательские строки (задел под локализацию)
|
|
validateFeedback.ts правила заполнения — чистая функция
|
|
validateFeedback.test.ts
|
|
useFeedbackForm.ts состояние формы, валидация, отправка
|
|
FeedbackForm.tsx сборка формы из секций
|
|
ThankYouScreen.tsx экран после отправки
|
|
sections/ секции формы
|
|
styles/
|
|
_design-tokens.scss фирменные токены (копия из request-portal)
|
|
global.scss
|
|
```
|
|
|
|
Состояние формы целиком живёт в `useFeedbackForm`; секции получают срез данных и
|
|
колбэк `set`, но своим состоянием не владеют.
|
|
|
|
## Что не сделано
|
|
|
|
**Отправка данных.** Бэкенда пока нет: `useFeedbackForm.submit` валидирует форму и
|
|
пишет результат в консоль (см. `TODO` в файле). Реальную интеграцию нужно подключить
|
|
отдельно — только там, без правок в компонентах.
|
|
|
|
**Деплой.** Тестовый workflow есть, деплоя нет — не решено, где и как будет жить
|
|
собранный `dist/`.
|