sut-report

## Major Points
1. ### 1. Onboarding
   - **Проблема**: во многих компонентах - например, `EditLeavePeriodDrawer`,
   дровер, отвечающий за создание и редактирование отсутствий (отпусков) -
   явно присутствует код, заполняющий форму данными, переданными через специальный проп.
   Таким образом компонент был изменён для решения посторонней задачи, а не, например,
   декорирован.
   - **Замечено**, что функционал этого онбординга (обучения) в текущем релизе (2023.3.1)
   по большей части не является рабочим или даже полностью реализованным.
   - **Решение**: полностью убрать текущую реализацию и/или переписать её как
   отдельную фичу, что позволит отключить её при ненадобности и гарантирует полное
   разделение кода.
UPD: Завели SPIKE - https://jira.moskit.pro/browse/SUT-4598

2. ### Routes and CRUD
   - **Проблема 1**: источником истины для кода фронта `SystemTagsEnum`
   являются данные в БД, которые записываются в исходники фронта
   вручную вызываемым скриптом в приложении бэкэнда через эндпоинт
   запущенного локально/по `env.API_BASE_URL` бэкэнда - в такой сложности нет
   никакой необходимости.
UPD: договорились на `"migration:run:dev": "npm run migration:run && npm run create-system-tags"`
   - **Проблема 2**: для добавления роута необходимо произвести миграцию, выполнить
   вышеупомянутый скрипт, и добавить записи ещё в двух файлах констант на фронте -
   тоже, получается, излишне сложный процесс с частичным дублированием кода.
   - **Проблема 3**: работа с параметрами, значения которых являются массивами, неудобна -
   компоненту-пользователю приходится самостоятельно производить `join`/`split` значения.
   - **Замечено**, что доступ к некоторым роутам определяется тэгами нескольких дочерних
   элементов, например, `/charts/[type]` - т.е. роуты образуют как минимум древовидную
   структуру (возможно, существуют и связи между различными ветками дерева, например,
   если какой-то виджет используется на нескольких разных страницах).
UPD:
1) Договорились на дерево роутов (нужны для тегов + title) (круто, если с i18n)
2) Подумать как убить дубликаты; или как кидать ts ошибку
Задача - https://jira.moskit.pro/browse/SUT-4599
3) Потрогать next 13.2 - type fase links
Задача (SPIKE) - https://jira.moskit.pro/browse/SUT-4599

   - **Решение**: сделать единым источником истины один `json` файл,
   используемый и бэком, и фронтом, описывающий карту сайта.
   Миграции базы данных будут производиться в соответствии
   с содержанием этого файла. Из-за зависимости объекта от самого себя -
   ключи родительских/дочерних роутов должны присутствовать в этом же объекте -
   и невозможности реализации такой проверки в Typescript без дублирования
   определения ключей, валидность этого файла должна будет проверяться отдельным
   pre-build скриптом. Кроме того, дублирующие роуты `withQuery` не имеют смысла,
   их нужно убрать, а работу с параметрами-массивами внести в `useRouter`.

3. ### User profile (kk-ui/UserForm)
   - **Проблема 1**: некоторые компоненты очень большие из-за отсутствия разделения на
   меньшие компоненты (например, разделы "Общине данные" и "Дополнительная информация").
   - **Проблема 2**: JSX некоторых компонентов перегружен, например логикой условного рендера
   режимов чтения и редактирования (флаг `readonly`), или логикой создания клибальной ссылки внутри компонентов
   типа TextField или Autocomplete.
   - **Проблема 3**: текущие типы, сгенерированные их схем бэк требуют, не образуют
   discriminated union, из-за чего в коде большое количество `@ts-expect-error`
   - **Проблема 4**: состояния `jotai` находятся в глобальном скоупе, что создаёт сложности в
   управлении и сбрасывании состояния - кроме того в проекте уже есть стейт менеджер `mobx`.
   - **Решение**:
     - Раздробить компоненты и распределить их по иерархии в файловой структуре.
     - Обобщить реализацию переключения `readonly` и ссылок, возможно отказаться или
     изменить реализацию `<HideableTextField />` (изначально был создан как раз
     для такого переключения ввиду странной вёрстки, при которой "просто" убирается рамка
     поля ввода).
     - Исправить схемы на бэке, чтобы из них генерировались удобные типы - discriminated union,
     либо раздельные типы; вероятно из-за текущей реализации taxios или спецификации
     openApi это невозможно.
     - Заменить использование `jotai` на контексты, `react-hook-form` или `mobx`.

4. ### exhaustive-deps
   - **Проблема**: очень много использований `eslint-disable-next-line react-hooks/exhaustive-deps`,
   что есть плохая практика в целом, и подаёт плохой пример стажёрам в частности.
   - **Решение**: зарезолвить все случаи недостающих зависимостей хуков, по необходимости
   используя `useRef` или `useAutoRef` (сразу создаёт `ref` объект из аргумента).
UPD: Завели задачу - https://jira.moskit.pro/browse/SUT-4601

5. ### Толстые компоненты
    - **Проблема**: есть ряд компонентов, размер которых превышает 200 строк (даже без jsx),
   что сильно ухудшает читаемость, например, `ProjectHierarchyTab`;
   часто в таких компонентах имеется повторение кода.
    - **Решение**: найти такие компоненты и упростить логику на месте или выносом в
   уже имеющиеся или новые компоненты/хуки иил вспомогательные файлы.

## Minor points

- Директория `const` - свалка; `components` - тоже похожа на свалку.
В каждой фиче - мини-свалка. Возможно стоит хотя бы начать внедрять feature-sliced или
какую-то другую более строгую иерархию.

- В палитре темы есть невнятная категория `dop`, куча различных бэкграундов,
разные форматы значений цветов.

- На страницах с фильтрациями/режимами передаются флаги `true/false`,
вместо использования `false` как значения по умолчанию
и передачи только ключа при включении флага,
i.e. `?bar` вместо `?foo=false&bar=true`.

- Тултипы у многих ячеек таблиц лишние, неплохо бы найти способ отображать
их только при `text-overflow`.

- Подсветка столбца в AgGrid мерцает при частом срабатывании ховера,
съедает много памяти и процессорного времени.

- `calc` в стилях - расстрел, кроме редких сложных случаев без
возможных альтернатив (наример `ReactTree` - дерево оргструктуры), а не `calc(50% - 16px)`.

- Во многих местах отступы имеют страшные значения типа 1.875 - 15px т.к. 1 юнит - 8px;
возможно лучше сделать 1 юнит - 4px и/или обсудить размеры и сетку с дизайнером.

- `npm audit` -> 44 vulnerabilities (17 moderate, 23 high, 4 critical).

- Во многих местах встречаются лишние оборачивающие `<Box />` (`<BaseWrapper />`),
часто с `width="100%"` и/или `height="100%"`, e.g. заголовок таблицы трудозатрат
и другие подобные таблицы.

- Бывают случаи, когда после нового релиза старые данные в `localStorage` ломают
какой-то функционал, e.g. последний релиз вызывал падение с 100 ошибками в секунду
на вкладке проектной иерархии любого проекта (так же почему-то там показывался
проект АИС) - необходимо валидировать хранимые там данные, и полностью
инвалидировать при их... невалидности.

- Часто используется хук `useTheme`, когда можно без него обойтись. Так же часто используется
длинная форма интерполяции функции `${({ theme }) => theme...}` вместо хелпера `${muiTheme...}`.

- В некоторых компонентах не используются хуки для локальных функций.

- Для табов можно сделать компонент на основе контекста.

- Многие Base-компоненты можно заменить на простой ре-экспорт и стилизовать с помощью `createTheme`.

- Есть ряд маркеров `@TODO` не касающихся того, что описано выше - тоже стоит исправить.

- При ошибке тайтл сайта превращается в `0: An unexpected error has occured` - ноль лишний.

- При сборке уведомления о деоптимизации подключенных из `assets/` svg файлов.
4 файла по 2-3 мегабайта занимают огромную часть бандла - потому что это на самом деле base64.

- `bundle-analyzer` - agGrid тянем дважды, `community` и `enterprise`.
В остальном всё достаточно осмысленно по размерам.

- `immutable` - используется в одном месте для резюме, возможно не нужен.