Files
hr-appeals/README.md
T
gorbenko.pavel 3cf46fa55c test: добавляет Vitest и CI-workflow по образцу request-portal
Покрыты чистые функции бизнес-логики: validateFeedback (обязательность полей
по видам обращения, минимальная длина текста, анонимность) и
getAppealFieldsConfig (согласованность конфига — обязательное поле не может
быть скрыто). React-компоненты пока не тестируются: сначала нужно решить,
куда форма отправляет данные, иначе тесты придётся сразу переписывать.

vite.config.ts: defineConfig теперь из 'vitest/config' — один файл конфига
на сборку и тесты вместо двух рассинхронизирующихся. globals: true и
environment: 'node', т.к. тестируется логика, а не DOM.

.gitea/workflows/test.yml — тот же принцип, что в request-portal (push в
main, PR, ретраи npm install), но npm run ci вместо heft test: здесь нет
SPFx/Jest, и деплой пока не добавлен — куда разворачивать dist/, не решено.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-21 09:45:05 +05:00

84 lines
4.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
```
Прочие команды:
```bash
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/`.