Что такое RTK Query

RTK Query нужен не просто для вызова fetch. Он помогает решить более важную задачу: как во frontend-приложении хранить и обновлять данные, которые пришли с сервера.

Без RTK Query для запроса часто приходится писать action types, thunk, reducer, поля loading и error, ручную очистку и повторную загрузку. В RTK Query вы переносите эту рутину в декларативное описание API. Вы описываете endpoint на backend, а библиотека создает action, reducer logic, middleware integration и React-хуки.

На интервью можно сказать коротко:

RTK Query - это встроенный в Redux Toolkit инструмент для server state. Он выполняет запросы, кэширует ответы, отслеживает подписки компонентов, дает статусы загрузки и помогает обновлять кэш после мутаций.

Минимальный пример показывает главный контракт: createApi описывает базовый запрос, endpoints и типы данных. React-хуки генерируются из имен endpoints.

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

type Post = {
  id: string;
  title: string;
};

export const postsApi = createApi({
  reducerPath: "postsApi",
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  tagTypes: ["Post"],
  endpoints: (builder) => ({
    getPosts: builder.query<Post[], void>({
      query: () => "posts",
      providesTags: ["Post"],
    }),
    addPost: builder.mutation<Post, Pick<Post, "title">>({
      query: (body) => ({
        url: "posts",
        method: "POST",
        body,
      }),
      invalidatesTags: ["Post"],
    }),
  }),
});

export const { useGetPostsQuery, useAddPostMutation } = postsApi;

В компоненте вы работаете не с ручным useEffect, а с hook, который уже связан с кэшем:

function PostsList() {
  const { data: posts = [], isLoading, isFetching, error } = useGetPostsQuery();
  const [addPost, { isLoading: isAdding, error: addError }] = useAddPostMutation();

  async function handleAddPost() {
    try {
      await addPost({ title: "New post" }).unwrap();
    } catch {
      // Show a user-friendly message near the action or keep it in mutation state.
    }
  }

  if (isLoading) return <p>Загружаем посты...</p>;
  if (error) return <p role="alert">Не удалось загрузить посты</p>;

  return (
    <section aria-busy={isFetching || isAdding}>
      {isFetching && <p>Обновляем данные...</p>}
      {posts.length === 0 ? (
        <p>Пока нет постов</p>
      ) : (
        <ul>
          {posts.map((post) => (
            <li key={post.id}>{post.title}</li>
          ))}
        </ul>
      )}

      {addError && <p role="alert">Не удалось добавить пост</p>}
      <button type="button" disabled={isAdding} onClick={handleAddPost}>
        {isAdding ? "Добавляем..." : "Добавить пост"}
      </button>
    </section>
  );
}

Практический вывод простой. Компонент становится короче, но ответственность не исчезает. Вам все равно нужно решить, когда refetch уместен, какие ошибки показать пользователю и как не оставить в кэше старый список. В UI важно не только получить данные. Нужно еще показать первую загрузку, empty state, фоновое обновление и ошибку так, чтобы пользователь не потерял контекст. Если просто вызвать mutation и не обработать отказ сервера, действие может выглядеть успешным, хотя данные не сохранились.

На интервью не стоит продавать RTK Query как универсальное решение для всего. Лучше назвать критерии выбора. Инструмент хорошо подходит, когда в проекте уже есть Redux Toolkit, REST-запросов много, данные нужны в разных частях приложения, а ручные slices для каждого запроса превращаются в шум.

Если задача маленькая, данные нужны в одном компоненте или команда уже использует другой зрелый инструмент для server state, выбор может быть другим. Ответ звучит увереннее, когда вы показываете trade-off, а не доказываете, что один инструмент всегда лучше.

Главная ловушка RTK Query в том, что кэш кажется полностью автоматическим. На деле он умеет хранить ответы и переиспользовать их, но бизнес-связь между запросами вы обычно описываете сами.

Например, список постов и мутация добавления поста связаны через тег Post. Query сообщает, что предоставляет данные этого типа. Mutation сообщает, что после успешного изменения эти данные нужно считать устаревшими. Если этого не сделать, пользователь может нажать Add, получить успех от сервера, но увидеть старый список до ручного обновления страницы.

RTK Query хранит копию серверных данных и управляет ее жизненным циклом. Это не значит, что все состояние приложения нужно переносить в API-кэш.

Хорошее разделение выглядит так:

• данные пользователя, список заказов, карточка товара - query cache;
• открыта ли модалка, выбранная вкладка, текст в поисковом поле - component state или обычный slice;
• черновик формы редактирования - form state или локальный state, пока пользователь не отправил mutation.

Плохой паттерн - без причины копировать data из query в useState и дальше показывать копию. При refetch кэш обновится, а локальная копия может остаться старой. Безопаснее читать серверные данные из hook, а отдельно хранить только то, что пользователь реально редактирует.

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

Поэтому в ответе стоит сказать не только, что RTK Query поддерживает optimistic updates. Важно добавить, что нужен rollback. В RTK Query для этого используют onQueryStarted и обновление кэша через utility methods. Если mutation падает, patch нужно откатить.

removePost: builder.mutation<void, string>({
  query: (id) => ({
    url: `posts/${id}`,
    method: "DELETE",
  }),
  async onQueryStarted(id, { dispatch, queryFulfilled }) {
    const patch = dispatch(
      postsApi.util.updateQueryData("getPosts", undefined, (draft) => {
        return draft.filter((post) => post.id !== id);
      })
    );

    try {
      await queryFulfilled;
    } catch {
      patch.undo();
    }
  },
})

Такой пример показывает зрелость ответа. Вы думаете не только о скорости, но и о консистентности данных и доверии пользователя.

RTK Query хорошо сочетается с TypeScript, потому что типы endpoint описывают и данные ответа, и аргумент запроса. В примере builder.query<Post[], void> означает, что hook вернет массив Post, а аргумент ему не нужен. builder.mutation<Post, Pick<Post, "title">> означает, что mutation принимает объект с title и возвращает созданный post.

Это не магия и не гарантия правильного runtime-ответа от backend. TypeScript помогает не передать неправильный аргумент и не обратиться к несуществующему полю. Но если сервер вернул неожиданный JSON, нужна валидация на границе или аккуратная обработка ошибки.

RTK Query не делает данные безопасными автоматически. Не рендерите HTML из ответа без санитайза, не кладите токены в query args и не отправляйте credential-запросы без понимания CSRF-защиты на backend. Для авторизации обычно используют общий слой вроде prepareHeaders, а не пробрасывают секреты из компонента в каждый hook.

Сильный ответ на вопрос, что такое RTK Query, можно построить так:

1. Назвать инструмент: часть Redux Toolkit для server state.
2. Объяснить, что он делает: запросы, кэш, статусы, подписки, хуки.
3. Показать пользу: меньше boilerplate, меньше ручного useEffect и reducers для API.
4. Добавить важный нюанс: после мутаций нужно думать про invalidation или ручное обновление кэша.
5. Провести границу: не заменяет все состояние приложения и не отменяет обработку ошибок.

Если ответить только определением, это прозвучит поверхностно. Если добавить кэш, инвалидацию, server state и пару рисков для UI, ответ будет похож на ваш опыт работы с инструментом, а не на пересказ документации.