Как вы относитесь к выполнению API-запросов непосредственно внутри UI-компонентов?

Почему не стоит делать запросы в компонентах

Когда API-запрос выполняется непосредственно внутри UI-компонента, компонент становится ответственным не только за отображение, но и за управление данными, ошибками и загрузкой. Это нарушает принцип единственной ответственности и приводит к дублированию кода, если несколько компонентов нуждаются в одних и тех же данных. Кроме того, такие компоненты сложно тестировать, так как приходится мокировать сетевые вызовы внутри каждого теста.

Как правильно организовать

Рекомендуется выносить логику запросов в отдельный слой — например, в сервисы или кастомные хуки. Это позволяет переиспользовать логику, упрощает тестирование и делает компоненты чистыми. Для управления состоянием данных часто используют Redux Toolkit или React Query, которые предоставляют удобные инструменты для кэширования и синхронизации.

// Плохо: запрос внутри компонента
function UserProfile() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetch('/api/user').then(r => r.json()).then(setUser);
  }, []);
  return <div>{user?.name}</div>;
}

// Хорошо: вынесенный хук
function useUser() {
  return useQuery('user', () => fetch('/api/user').then(r => r.json()));
}

function UserProfile() {
  const { data: user } = useUser();
  return <div>{user?.name}</div>;
}

Когда это допустимо

В небольших прототипах или одноразовых компонентах можно делать запросы напрямую, но в production-коде лучше следовать описанным практикам. Это особенно важно в крупных приложениях, где данные используются в разных местах и требуется централизованное управление.

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