Инспектирование состояния кэша

В основе механизма кэширования RTK Query лежит нормализованное хранение результатов запросов внутри Redux store. Каждый endpoint формирует ключи кэша на базе аргументов запроса, а состояние хранится в виде дерева с разделением на queries, mutations и служебные метаданные.

Основной фрагмент состояния:

  • state.api.queries — кэш успешных запросов
  • state.api.mutations — состояние мутаций
  • state.api.provided — связи тегов и сущностей (используется для инвалидации)

Каждый элемент в queries содержит не только данные ответа, но и метаинформацию:

  • статус запроса (pending, fulfilled, rejected)
  • временные метки
  • данные ответа (data)
  • ошибки (error)
  • подписчики (subscribers)
  • параметры запроса (query args)

Инспектирование этого слоя позволяет точно понимать поведение кэша, причины повторных запросов и моменты рефетча.

Доступ к состоянию кэша через Redux store

RTK Query полностью интегрирован в Redux, поэтому состояние кэша доступно через store.getState().

const state = store.getState();
const apiState = state.api;

Далее интерес представляет структура queries:

const queries = state.api.queries;

Каждый ключ в queries — это сериализованный аргумент запроса.

Пример:

{
  "getUser({id:1})": {
    status: "fulfilled",
    endpointName: "getUser",
    originalArgs: { id: 1 },
    data: { id: 1, name: "Alex" },
    fulfilledTimeStamp: 1710000000000
  }
}

Использование selector-API для инспекции кэша

RTK Query предоставляет встроенные селекторы, которые предпочтительнее прямого доступа к state, так как учитывают мемоизацию и внутренние оптимизации.

Селектор конкретного запроса

const selectUser = api.endpoints.getUser.select({ id: 1 });

const result = selectUser(store.getState());

Возвращаемая структура:

{
  data,
  status,
  isLoading,
  isFetching,
  isSuccess,
  isError,
  error,
  requestId,
  endpointName,
  originalArgs
}

Инспекция через селекторы позволяет отслеживать состояние конкретного кэша без ручного разбора state.api.queries.

Наблюдение за состоянием через useSelector

В React-интеграции RTK Query можно напрямую наблюдать состояние кэша через useSelector:

const userQueryState = useSelector(
  api.endpoints.getUser.select({ id: 1 })
);

Каждое изменение кэша вызывает перерендер компонента, если изменяется выбранный фрагмент состояния.

Важно, что RTK Query минимизирует лишние обновления за счёт:

  • структурного сравнения результата селектора
  • мемоизации данных
  • стабильности ссылок при неизменном кэше

Внутренние метаданные и их интерпретация

Каждый cache entry содержит служебные поля, которые позволяют анализировать поведение запроса.

Статусы

  • pending — запрос выполняется
  • fulfilled — данные успешно получены
  • rejected — ошибка выполнения

Флаги активности

  • isFetching — активный сетевой запрос
  • isLoading — первый запрос без кэша
  • isSuccess — успешное завершение
  • isError — ошибка

Временные метки

fulfilledTimeStamp используется для:

  • вычисления устаревания данных
  • триггера refetchOnMountOrArgChange
  • анализа частоты обновлений

Анализ ключей кэша и аргументов запроса

RTK Query сериализует аргументы запроса для формирования ключа. Это означает, что инспектирование кэша требует понимания того, как именно формируется строка ключа.

Пример:

getUser({ id: 1 })
getUser({ id: 2 })

Будут два независимых ключа.

Однако:

getUser(1)
getUser({ id: 1 })

Могут привести к разным кэш-ячейкам, если сериализация отличается.

Поэтому при инспектировании важно анализировать:

  • originalArgs
  • endpointName
  • сериализованный ключ

Работа с devTools и визуальная инспекция кэша

Redux DevTools предоставляет полную картину RTK Query store.

В состоянии можно наблюдать:

  • обновления queries
  • появление новых ключей кэша
  • удаление устаревших записей
  • refetch-события

Особенно полезны следующие сценарии:

  • сравнение состояния до и после мутации
  • отслеживание инвалидации тегов
  • анализ повторных запросов при монтировании компонентов

Инспектирование через middleware lifecycle

RTK Query middleware генерирует lifecycle actions:

  • api/executeQuery/pending
  • api/executeQuery/fulfilled
  • api/executeQuery/rejected

Каждое действие содержит:

  • meta.requestId
  • meta.arg
  • payload (для fulfilled)
  • error (для rejected)

Пример анализа:

store.subscribe(() => {
  const actions = actionLog.getLast();
  console.log(actions);
});

Это позволяет отслеживать, как именно изменяется кэш в реальном времени.

Сравнение кэша между состояниями

Для глубокого анализа часто требуется сравнение snapshot-ов состояния.

Пример подхода:

const prev = previousState.api.queries;
const next = currentState.api.queries;

const diff = Object.keys(next).filter(
  key => prev[key] !== next[key]
);

Это позволяет выявить:

  • обновлённые записи
  • инвалидированные ключи
  • новые запросы

Инвалидация и влияние на кэш

Система тегов напрямую влияет на структуру кэша.

Когда выполняется:

invalidatesTags: ["User"]

RTK Query:

  • помечает связанные записи как устаревшие
  • инициирует refetch подписанных запросов
  • обновляет provided карту

Инспекция:

state.api.provided

показывает соответствие:

  • тег → список query keys

Это ключевой инструмент анализа причин автоматических обновлений данных.

Отладка повторных запросов через кэш

Повторные запросы часто связаны не с ошибками API, а с политиками кэширования:

  • refetchOnMountOrArgChange
  • refetchOnFocus
  • refetchOnReconnect
  • истечение keepUnusedDataFor

Инспектирование включает проверку:

  • времени жизни записи
  • количества подписчиков
  • момента удаления из кэша

Пример анализа подписчиков:

state.api.queries[key].subscriptions

Если subscriptions пустой, запись становится кандидатом на удаление.

Низкоуровневое наблюдение за жизненным циклом кэша

Полный цикл cache entry:

  1. создание ключа при dispatch запроса
  2. установка pending
  3. выполнение HTTP-запроса
  4. переход в fulfilled или rejected
  5. обновление подписчиков компонентов
  6. возможная инвалидация через tags
  7. удаление при отсутствии подписчиков

Каждый шаг отражается в состоянии store и может быть отследен через middleware или DevTools.

Практическая модель анализа состояния кэша

При комплексной диагностике обычно анализируются одновременно:

  • state.api.queries — текущие данные
  • state.api.mutations — активные операции записи
  • state.api.provided — связи тегов
  • lifecycle actions — история изменений
  • селекторы endpoint’ов — актуальное состояние UI

Совокупность этих источников позволяет восстановить полную картину поведения RTK Query без внешних инструментов.

Оглавление