Работали ли вы с React Query?

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

Отличаете ли вы серверное состояние от клиентского и понимаете ли, что именно берёт на себя библиотека: кэш по ключу, дедупликацию запросов, фоновое обновление, повторы. Форма вопроса закрытая, но оценивают глубину, а не факт знакомства.

Как отвечать

Скажите, что React Query (TanStack Query) это менеджер серверного состояния, и пройдитесь по механике:

• ключ запроса: кэш адресуется массивом queryKey, одинаковый ключ в разных компонентах даёт один сетевой вызов;
• staleTime и gcTime: первое отвечает, сколько данные считаются свежими, второе, сколько неиспользуемая запись живёт до удаления. Это разные вещи, и их путают чаще всего;
• фоновые рефетчи: при монтировании, возврате фокуса в окно и восстановлении сети;
• мутации: useMutation плюс queryClient.invalidateQueries по затронутым ключам, либо оптимистичное обновление через setQueryData с откатом в onError;
• состояния загрузки: isPending против isFetching, placeholderData чтобы список не мигал при пагинации.

const { data, isPending } = useQuery({
  queryKey: ["jobs", filters],
  queryFn: () => fetchJobs(filters),
  staleTime: 60_000,
});

Полезно добавить, где библиотека не нужна: локальное состояние формы и модалок она не заменяет.

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

Отвечают «она сама кэширует» и на этом останавливаются. По умолчанию данные считаются устаревшими сразу, поэтому запрос повторяется при каждом монтировании и возврате фокуса. Нужный интервал свежести задаёт разработчик, исходя из того, как быстро меняются данные.

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

Третье: собирают ключ из части параметров. Фильтры меняются, ключ прежний, и два разных набора данных делят одну запись кэша. Всё, от чего зависит ответ сервера, обязано входить в ключ.