Стоит ли писать логику в React-компонентах, выносить её в хуки или вообще стараться выносить бизнес-логику вне React?

Вопрос о том, где размещать логику в React-приложении, сводится к принципу разделения ответственности. Компонент должен отвечать за то, как выглядит интерфейс и как он реагирует на действия пользователя, а не за то, как устроены правила предметной области. Если смешать всё в одном месте, компонент становится большим, его сложно тестировать и переиспользовать.

Три уровня логики

• UI-логика — условный рендеринг, обработка кликов, локальное состояние отображения. Живёт прямо в компоненте.
• Логика состояния и эффектов — подписки, таймеры, синхронизация с внешними источниками. Хорошо ложится в кастомные хуки.
• Бизнес-логика — расчёты, валидация, правила, работа с API. Должна быть чистыми функциями или сервисами вне React.

Почему бизнес-логику лучше выносить

Чистая функция без зависимостей от React легко тестируется, переиспользуется в других местах (например, на сервере или в мобильном приложении) и не ломается при обновлении React. Хук же остаётся тонким адаптером: он вызывает сервис и отдаёт результат в компонент.

// domain/cart.js — чистая бизнес-логика
function calcTotal(items) {
  return items.reduce((sum, i) => sum + i.price * i.qty, 0);
}

// hooks/useCart.js — адаптер для React
function useCart(items) {
  return useMemo(() => calcTotal(items), [items]);
}

// Cart.jsx — только UI
function Cart({ items }) {
  const total = useCart(items);
  return <div>Total: {total}</div>;
}

Когда что применять

1. Логика нужна только одному компоненту и не переиспользуется — оставляйте в компоненте.
2. Логика повторяется в нескольких компонентах — выносите в кастомный хук.
3. Логика не зависит от React и содержит правила предметной области — выносите в отдельный модуль или сервис.

Итог: держите компоненты тонкими, хуки — как переиспользуемые адаптеры, а бизнес-логику — в независимых модулях. Такой подход упрощает тестирование, повторное использование и поддержку кода.