Для каких случаев удобно использовать React Query?

React Query удобен везде, где компонентам нужны данные с сервера: он превращает «запрос + состояния + кеш + обновление» из ручной работы в декларативное описание.

Типовые случаи

Списки и детали с CRUD. Каталог, заказы, профиль: useQuery на чтение, useMutation на изменение с инвалидацией:

const { data, isPending } = useQuery({ queryKey: ['orders'], queryFn: api.getOrders });
const create = useMutation({
  mutationFn: api.createOrder,
  onSuccess: () => queryClient.invalidateQueries({ queryKey: ['orders'] }),
});

Одни данные во многих местах. Шапка, сайдбар и страница используют профиль: одинаковый queryKey → один запрос, общий кеш, синхронное обновление везде — без стора и prop drilling.

Пагинация и бесконечные списки. useInfiniteQuery для бесконечных списков, для постраничных — useQuery с placeholderData: keepPreviousData (v5): страницы подгружаются, старые не мигают.

Данные, требующие свежести. Дашборды, нотификации: refetchInterval, refetchOnWindowFocus — данные сами обновляются в фоне.

Оптимистичный UI. Лайки, чекбоксы задач: onMutate обновляет кеш мгновенно, при ошибке — откат.

Зависимые и параллельные запросы. enabled: !!userId — цепочки без каскадов ручных эффектов.

Медленные/ненадёжные API. Ретраи с backoff, кеш «сначала показываем старое, потом обновляем» (stale-while-revalidate).

Когда НЕ нужен

Чисто клиентское состояние (формы, UI-флаги) — это useState/Zustand; WebSocket-стримы как основной канал — своя логика (хотя кеш RQ можно обновлять из сокета); GraphQL со сложными нормализованными кешами — Apollo.

Коротко для собеседования

React Query удобен для: серверных CRUD-данных со статусами и инвалидацией, шаринга данных между компонентами через общий кеш (дедупликация), пагинации/infinite scroll, фонового автообновления, оптимистичных обновлений и ретраев. Не для клиентского состояния — там useState/стор.