Предыстория…

Эта короткая статья является частью серии статей, которые являются ответвлениями от основной статьи (которая является основой) о некоторых распространенных случаях использования RTK Query (Redux ToolKit Query).

В этой части мы поговорим о механизме кэширования RTK Query.

ПРИМЕЧАНИЕ. Эта статья не является введением в RTK Query (начать можно здесь).

Кеширование ребенка! 🏦

Одним из преимуществ использования RTKQ является кэширование, особенно если вы уже используете Redux для управления состоянием.

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

Но как RTKQ делает это? Количество ссылок.

Счетчик ссылок

RTKQ отслеживает абонентов данной конечной точки.
Мы суммируем счетчик ссылок для каждого хука конечной точки (не все) или инициируем (читай здесь), который мы используем.
Для данной конечной точки, если счетчик ссылок достигает нуля, кэшированные данные удаляются. хранится до keepUnusedDataFor (значение по умолчанию равно 60 секундам).

Но что, если мы хотим аннулировать его?

Повторная выборка данных/аннулирование кеша
Очевидно, что мы хотим сделать наш кеш недействительным по многим причинам — будь то из-за конечной точки зависимой мутации или пришло время получить свежие новые данные.
Существует несколько способов обновить или аннулировать кеш определенной конечной точки или API (в зависимости от вашего варианта использования):

  • keepUnusedDataFor — Как описано выше, таким образом, все подписчики должны отписаться, и должно пройти время keepUnusedDataFor.
  • refetch — обычно функция, предоставляемая используемым вами хуком, например: const { data, refetch } = useGetPostsQuery();
    Мы получим свежие данные с нашего сервера при вызове refetch.
  • Tags — это изящный способ создать зависимость (отношения) между конечными точками (и не только), что означает, что если у вас есть запрос GET, который должен инициироваться снова, когда мутация (POST или другая конечная точка мутации, которая у вас есть) выполняется для данных, которые она получает.

Вот как это сделать:
1. tagTypes — укажите типы тегов для прослушивания вашим API:

2. provideTags. Предоставьте теги вашей конечной точке для прослушивания, поэтому в случае их изменения кеш будет недействительным для этой конечной точки.

3. invalidateTags — эта часть является триггерной точкой для аннулирования тега (аннулирования кеша).
Как только это будет прикреплено к конечной точке мутации, слушатели (конечные точки) для этого тега испытают недействительность кеша для своих данных, что вызовет другой вызов выборки.

Недействительность тегов может стать более сложной и специфичной, если у вас есть вложенные данные, поэтому ознакомьтесь с разделом теги для получения дополнительных примеров.
Я хотел бы отметить, что теги предназначены не только для успешных вызовов API, вы можете также инвалидировать теги за неуспешные вызовы (подробнее здесь).

  • resetApiState — Если вы хотите стереть кэшированные данные всего API, отправьте это действие: dispatch(api.util.resetApiState());

Другие способы управления поведением кеша можно найти здесь.

Краткое содержание

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

Если у вас есть какие-либо комментарии или вопросы, я буду рядом с разделом комментариев.

Спасибо и не стесняйтесь обращаться!

Ссылки: Документация RTK Query