В чем смысл React Query и зачем он нужен, если можно делать fetch напрямую

Что проверяют

Отличаете ли вы состояние сервера от состояния интерфейса и понимаете ли, сколько работы прячется за словами «просто сделать fetch».

Как отвечать

Начните с главной мысли: данные с сервера это не состояние компонента, а кеш чужих данных. У него своя жизнь: он устаревает, его нужно обновлять, он общий для нескольких экранов. Держать такой кеш в useState значит писать эту логику заново в каждом компоненте.

Что даёт библиотека помимо самого запроса:

• кеш по ключу: два компонента с одним ключом делают один запрос, второй получает готовые данные мгновенно;
• состояния из коробки: загрузка, ошибка, обновление в фоне, пустой результат. Руками это три useState и useEffect в каждом месте;
• устаревание и обновление: данные считаются свежими заданное время, потом обновляются в фоне при возврате на вкладку или переподключении сети, а пользователь всё это время видит прежние значения;
• повторные попытки при сетевых сбоях и отмена запросов при размонтировании;
• гонки запросов: при быстрой смене фильтров ответ на старый запрос не перезапишет свежие данные, а это одна из самых неприятных ошибок ручного кода;
• инвалидация после изменений: отправили форму, пометили ключ устаревшим, списки обновились сами;
• пагинация и бесконечная прокрутка, оптимистичные обновления с откатом при ошибке.

Честно скажите и когда она не нужна: пара запросов на всё приложение, или данные и так приходят с сервера при рендере, как в Next.js с серверными компонентами. Тогда библиотека это лишняя зависимость.

Где спотыкаются

Кладут ответ сервера в глобальное хранилище состояния рядом с состоянием интерфейса и потом руками синхронизируют.

Пишут свой useFetch и забывают про отмену и гонки, из-за чего на быстром вводе в поиск иногда показывается ответ на предыдущий запрос.

Считают, что библиотека заменяет хранилище состояния: она про серверные данные, а состояние интерфейса живёт отдельно.