Files
hr-appeals/README.md
T
gorbenko.pavel 0eb81e61e5 chore: npm run dev поднимает фронтенд и auth-сервис вместе
Локальное окружение требовало двух терминалов, а без запущенного
auth-сервиса форма отдаёт 500 от vite-прокси — это легко принять за баг
приложения. Теперь concurrently стартует оба процесса с метками
[web]/[auth]; только фронтенд — npm run dev:web.

Заодно поправлен README сервиса: GRAPH_SCOPE больше не нужно задавать
руками, дефолт уже указывает на App ID URI api.tnsu.kz.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:57:36 +05:00

5.2 KiB

hr-appeals

Форма обращений сотрудников в HR департамент.

Заменяет встроенную Microsoft Forms: даёт собственный интерфейс в фирменном стиле (общие токены и компоненты, что и request-portal) без чужого брендинга и служебных плашек в подвале.

Стек

  • React 17 + TypeScript (строгий режим)
  • Vite 6
  • SCSS Modules
  • @tnsu/ui-kit — общие UI-компоненты
  • Vitest — тесты бизнес-логики

React именно 17-й: @tnsu/ui-kit объявляет его в peerDependencies.

Запуск

Пакеты @tnsu/* лежат в приватном реестре — он прописан в .npmrc, отдельная настройка не нужна, но нужен доступ к git.tnsu.kz.

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 с сертификатом Azure AD — скопируйте server/.env.example и подставьте свои пути. Сами .pem-файлы в git не хранятся, их надо взять у администратора. Подробнее — в server/README.md.

Прочие команды:

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/.