Какие плюсы и минусы React Query?

TanStack (React) Query — библиотека управления серверным состоянием: кеш запросов, синхронизация, мутации.

Плюсы

• Убирает бойлерплейт: вместо useEffect + isLoading + error + отмена — один useQuery со статусами.
• Кеш и дедупликация: компоненты с одинаковым queryKey делят один запрос и данные; никакого prop drilling и «данных в Redux».
• Свежесть из коробки: stale-while-revalidate (мгновенный показ кеша + фоновая перезагрузка), refetch при фокусе/реконнекте, интервалы.
• Надёжность: ретраи с backoff, отмена, защита от гонок.
• Мутации: инвалидация кеша, оптимистичные обновления с откатом.
• Пагинация и бесконечные списки, префетч, Suspense-режим, отличные девтулзы.
• Как следствие — глобальный стор часто становится не нужен.

Минусы

• Ещё одна абстракция: свой словарь (queryKey, staleTime, gcTime, invalidate) и порог входа; неверные ключи → «данные не обновились».
• Не нормализованный кеш: одна сущность может лежать в нескольких запросах; при сложных связях нужна ручная инвалидация (в отличие от Apollo/RTK Query с тегами/нормализацией).
• Не для клиентского состояния: UI-флаги, корзина, формы — не её задача.
• Размер бандла и лишний слой для приложения с двумя запросами.
• Realtime (WebSocket) требует ручной синхронизации кеша.

Когда выбирать

Практически всегда, когда приложение живёт на серверных данных со списками, деталями и CRUD. Не выбирать: пара статических запросов; GraphQL со сложной нормализацией (Apollo/urql); стек уже на Redux — тогда RTK Query.

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

Плюсы: кеш с дедупликацией и фоновым обновлением, статусы и ретраи без бойлерплейта, мутации с инвалидацией и оптимистичными апдейтами, девтулзы; серверные данные уходят из стора. Минусы: порог входа и дисциплина ключей, кеш не нормализован (ручная инвалидация связей), не для клиентского состояния, оверхед на простых приложениях.