Code Review Guidelines для OnlyTraffic CRM Frontend

Общие принципы

Архитектура и структура

Shared код: Убедитесь, что общий функционал не дублируется между shared и features. Код должен быть в shared папке, если используется в нескольких местах.
Состояние и store: Проверяйте корректность обработки состояния в MobX stores, особенно при работе с nullable значениями.
Type safety: Все новые поля в типах должны иметь явное определение типа, предпочтительно с optional chaining для nullable значений.
Минимизация useState/useEffect: Минимизировать использование useState/useEffect, логику выносить в mobx сторы, кроме shared слоя. В shared/components компоненты должны быть без сторов.
Размер компонентов и сторов: Компоненты и сторы не должны быть объемными (условно не больше 600 строк), разбивать на логические части.

Специфичные проблемы для внимания

1. Обработка null/undefined значений

Критично

Всегда проверяйте обработку null и undefined в формах и stores
Используйте дефолтные значения (??) вместо условных фильтров

Пример из PR #562:

// ❌ Плохо
permissions.filter((p) => !!p.dataAccess).forEach(...)

// ✅ Хорошо
const access: DataPermissions = p.dataAccess ?? 'SELF';

2. Локализация (i18n)

Обязательно

Все новые текстовые строки должны быть в файлах локализации
Проверяйте наличие переводов для всех языков (en, ru и т.д.)
Ключи локализации должны быть структурированы иерархически

Пример структуры:

{
  "ComponentName": {
    "title": "...",
    "description": "...",
    "error": "...",
    "success": "..."
  }
}

3. CSS и стили

Важно

Используйте CSS-переменные вместо хардкода цветов
Проверяйте поддержку как светлой, так и темной темы
Изменения в primitives.css должны отражаться в dark.css и light.css

Пример из PR #553:

/* ✅ Используйте переменные */
background-color: var(--bg-surface-content) !important;

/* ❌ Не используйте хардкод */
background-color: #121214 !important;

4. React компоненты

Критично

useEffect dependencies: Проверяйте корректность массива зависимостей
Refs: Используйте useRef для мутируемых значений, которые не должны вызывать ререндер
Event handlers: Стабилизируйте обработчики через useCallback или refs для предотвращения ненужных подписок/отписок

Пример из PR #566:

// ✅ Стабильный ref для обработчика
const handleInsertRef = useRef(handleInsert);
handleInsertRef.current = handleInsert;

5. Логика форм и input

Обязательно

Проверяйте edge cases: пустые значения, специальные символы, длинные строки
Валидация должна быть как на фронте, так и на беке
Для boolean полей используйте явное приведение типов
Дефолтные значения должны быть заданы на уровне типов или при инициализации

6. API интеграция

Важно

Все запросы должны иметь обработку ошибок
Проверяйте правильность payload перед отправкой (особенно для undefined значений)
Регенерируйте API типы после изменения Swagger спецификации (yarn gen-api)

Пример из PR #562:

// ✅ Проверка перед отправкой
return {
  code,
  dataAccess: node ? (node.scope?.length ? dataAccess : undefined) : dataAccess,
};

7. Рефакторинг и оптимизация

Рекомендуется

При рефакторинге убирайте устаревший код, не оставляйте закомментированные куски
Если меняете логику, проверьте влияние на связанные компоненты
Разделяйте useEffect по ответственности (не смешивайте разные side-effects)

8. UI/UX специфика

Важно

Enter блокировка: При работе с OnlyFans интеграцией учитывайте особенности блокировки Enter для предотвращения случайной отправки
Пустые состояния: Проверяйте корректность обработки пустого редактора
Double-click protection: Используйте флаги состояния для предотвращения повторных кликов (из PR #555)

Пример из PR #566:

// ✅ Не блокировать Enter для пустого редактора
if (!text) return;

9. TypeScript

Обязательно

Избегайте any, используйте точные типы
Новые интерфейсы должны быть экспортированы из соответствующего модуля
Optional поля (?:) должны иметь fallback значения при использовании
Используйте union types для ограниченного набора значений
После изменения API регенерируйте типы через yarn gen-api

10. Performance

Рекомендуется

Минимизируйте количество ререндеров через мемоизацию
Используйте виртуализацию для больших списков
Избегайте создания функций в render
Оптимизируйте работу с RAF (requestAnimationFrame) для UI обновлений

11. Permissions и Authorization

Критично (из PR #555)

Всегда проверяйте права доступа перед отображением UI элементов
Дизейблите кнопки для системных ролей (Owner, Admin)
Проверяйте permissions перед выполнением действий
Показывайте tooltips для объяснения недоступности функций

Пример:

// ✅ Проверка permissions
const canDuplicate = !role.isSystem && hasPermission('canCreateRole');

12. State Management (isDuplicating, isLoading)

Важно (из PR #555)

Используйте флаги состояния для предотвращения race conditions
Дизейблите кнопки во время выполнения запросов

Пример:

const [isDuplicating, setIsDuplicating] = useState(false);

const handleDuplicate = async () => {
  if (isDuplicating) return;
  setIsDuplicating(true);
  try {
    await api.duplicate();
  } finally {
    setIsDuplicating(false);
  }
};

13. Toasts и User Feedback

Обязательно

Success/error toasts должны быть локализованы
Показывайте конкретные сообщения об ошибках
Используйте toasts для подтверждения действий

Пример структуры локализации:

{
  "success": "Роль дублирована",
  "error": "Не удалось дублировать роль"
}

14. Test Plans и Documentation

Рекомендуется (из PR #555, #546)

Включайте test plan в описание PR
Используйте чеклисты для проверки функциональности
Документируйте edge cases
Указывайте зависимости от backend PR

Пример:

## Test plan
- [ ] Copy icon visible on non-system roles
- [ ] Copy icon disabled on system roles
- [ ] Double-click protection works

**Depends on:** backend PR #123

15. File Upload и Media

Важно (из PR #496)

Проверяйте размеры загружаемых файлов
Валидируйте типы файлов
Показывайте прогресс загрузки
Обрабатывайте ошибки загрузки с понятными сообщениями

16. Lint и Code Style

Обязательно (из PR #496)

Код должен проходить ESLint без ошибок
Следуйте единому code style проекта
Используйте Prettier для форматирования
Перед коммитом запускайте yarn lint:fix

Checklist для reviewer

Перед approve проверьте:

Red flags 🚩

Сразу запрашивайте изменения если:

Есть any типы без веской причины
Null/undefined не обработаны должным образом
Хардкод цветов вместо CSS переменных
Отсутствует локализация для пользовательских строк
useEffect без dependencies или с неполным списком
Дублирование существующего функционала
Отсутствует обработка ошибок API
Изменения в shared без обновления зависимых мест
Нет double-click protection для важных действий
Отсутствуют проверки permissions
Не регенерированы API типы после изменений
Большие изменения без test plan

✅ "Рекомендую использовать ?? вместо || для дефолтных значений"
✅ "Этот код дублируется в компоненте X, можно вынести в shared"
✅ "Добавь double-click protection для этой кнопки"
✅ "Не хватает проверки permissions перед действием"
❌ "Плохо"
❌ "Переделай"

Используйте suggestion блоки в GitHub для простых правок:

const value = props.value ?? defaultValue;

Полезные команды

# Регенерация API типов
yarn gen-api

# Проверка линтера
yarn lint

# Автофикс линтера
yarn lint:fix

# Запуск тестов
yarn test

Lodo4ka/code-review-guidelines.md

Select an option

No results found

Select an option

No results found

Code Review Guidelines для OnlyTraffic CRM Frontend

Общие принципы

Архитектура и структура

Специфичные проблемы для внимания

1. Обработка null/undefined значений

2. Локализация (i18n)

3. CSS и стили

4. React компоненты

5. Логика форм и input

6. API интеграция

7. Рефакторинг и оптимизация

8. UI/UX специфика

9. TypeScript

10. Performance

11. Permissions и Authorization

12. State Management (isDuplicating, isLoading)

13. Toasts и User Feedback

14. Test Plans и Documentation

15. File Upload и Media

16. Lint и Code Style

Checklist для reviewer

Red flags 🚩

Комментарии

Полезные команды