Какие преимущества RTK Query
Что проверяют
Понимаете ли вы, что серверные данные это кэш, и знаете ли, когда лучше взять другой инструмент.
Как отвечать
RTK Query это часть Redux Toolkit для работы с серверными данными. Главная идея: данные с сервера это кэш, а не состояние приложения, и обращаться с ними надо соответственно.
Что он даёт вместо ручного кода:
- автоматические состояния запроса: идёт загрузка, есть данные, произошла ошибка, идёт фоновое обновление. Больше не нужны три поля состояния на каждый запрос и санк к ним;
- кэш с инвалидацией по тегам: запрос помечается тегом, изменяющая операция объявляет, какие теги портит, и связанные запросы обновляются сами. Это заменяет ручную рассылку сообщений «данные изменились»;
- дедупликация: три компонента запросили одно и то же, ушёл один запрос;
- генерация хуков из описания конечных точек, вместе с типами;
- повторное получение при возврате фокуса на вкладку и при восстановлении соединения;
- оптимистичные обновления и периодический опрос;
- кодогенерация из описания OpenAPI: клиент строится по контракту, и расхождение с бэкендом ловится на этапе сборки;
- видимость в инструментах Redux: весь кэш и все действия видны в отладчике, что удобно при разборе проблем.
Итог по объёму кода: типичный набор из среза, санка, трёх типов действий и обработчиков для одного запроса сжимается до нескольких строк описания.
Честная оговорка, без которой ответ неполный: если Redux в проекте не нужен для клиентского состояния, тянуть его ради работы с сервером не стоит. TanStack Query решает ту же задачу без Redux и гибче по управлению кэшем. RTK Query выигрывает там, где Redux уже есть, и хочется одного инструмента и единой панели отладки.
Где спотыкаются
Кладут ответы API в обычные срезы вручную.
Не используют теги и обновляют данные принудительной перезагрузкой.
Тянут Redux в проект только ради работы с сервером.
Считают кэш RTK Query состоянием приложения и дублируют его в срезах.