Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 RTK Query- это инструмент для создания сервисов для запросов на сервер. Он позволяет создавать удобные интерфейсы, благодаря которым мы можем отслеживать состояния запросов и при этом не создавать много однообразного кода.

2 <h2>Для чего нужен RTK Query</h2>

3 Часто в приложениях мы делаем запросы к серверу. Чтобы отслеживать состояние этих запросов, приходится писать много однотипного кода. Даже createAsyncThunk() не сильно помогает с такой задачей:

4 На каждое изменение запроса приходится добавлять свой редюсер, при этом код не сильно отличается. А если мы захотим отслеживать состояние каждого запроса по отдельности, то придется для этого еще и расширять состояние, чтобы хранить в нем все статусы запросов и ошибки.

5 Для решения таких задач был создан инструмент RTK Query. Он позволяет создать API для запросов на сервер с минимумом кода. Под капотом он использует createSlice и createAsyncThunk, но делает их использование более удобным.

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

7 <h2>Создание API</h2>

8 Рассмотрим создание простого API для четырех роутов:

9 Здесь мы создали API с помощью функции createApi(). Функция принимает объект, описывающий наше API:

10 <ul><li>reducerPath - название для стейта, можно применить при создании слайса</li>

11 <li>baseQuery - базовый URL для запросов. Здесь мы использовали функцию fetchBaseQuery() для создания URL, этот URL будут использовать все запросы в API</li>

12 <li>endpoints - здесь мы описываем сами запросы. В свойство передается функция, которая принимает объект builder - он позволяет настраивать API. Функция возвращает объект, в котором каждое свойство описывает нужный запрос.</li>

13 </ul>Разберем подробнее объект, который возвращается из функции в endpoints. Как следует из названия, функция создаетэндпоинты(конечные точки).

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

15 Каждый эндпоинт настраивается с помощью объекта builder. Для простых эндпоинтов, которые должны сделать get-запрос, используется метод builder.query(). В метод передается объект со свойством query() - это функция, формирующая запрос.

16 Для формирования первого эндпоинта, получающего список пользователя, мы определили функцию query: () => ''. Здесь мы возвращаем строку, потому что базовый URL уже содержит адрес получения списка пользователей: /api/users.

17 Следующий эндпоинт уже изменяет этот адрес, потому что нам нужно добавить идентификатор пользователя: query: (id) => id. Здесь id добавится к базовому адресу /api/users/:id.

18 Для эндпоинтов, которые вносят изменения в данные, мы можем использовать метод builder.mutation(). Он работает похожим образом как query(), но позволяет больше настроить запрос - изменять HTTP-метод или добавлять тело запроса.

19 <h2>Подключение API к стору</h2>

20 Разберемся, как подключить наше API к стору:

21 Созданное API предоставляет редюсеры, а также мидлвару. Как видите, основной подход не меняется, к стору точно так же подключаются новые редюсеры и мидлвара. Здесь мы используем reducerPath для указания имени группы редюсеров. Нам не нужно создавать слайс и описывать редюсеры - благодаря createApi(), все это сделано за нас.

22 <h2>Кэш</h2>

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

24 По умолчанию кэш устаревает за 60 секунд. После этого RTK Query пометит кэш как устаревший, и при новом запросе обновит его. Можно вручную задать время жизни кэша с помощью свойства keepUnusedDataFor:

25 <h2>Хуки для компонентов</h2>

26 Теперь осталось разобрать, как использовать API в компонентах. Созданное API предоставляет автоматически сгенерированные хуки для каждого действия:

27 Это позволяет сразу использовать API в компонентах без диспатча, что очень удобно. Ниже хук, созданный builder.query():

28 Пример хука для запроса с параметром:

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

30 Хук дает все необходимое, чтобы отслеживать запрос:

31 <ul><li>isLoading - если нам нужно отследить загрузку, например, для блокирования формы на время отправки запроса</li>

32 <li>status - содержит строковое значение текущего состояния запроса. Дает больше информации, чем isLoading</li>

33 <li>isError - если во время запроса была ошибка, то будет равен true</li>

34 <li>error - содержит данные ошибки, если возникла</li>

35 <li>data - результат запроса</li>

36 <li>refetch() - при вызове этой функции, RTK Query пометит текущее состояние эндпоинта как устаревшее и вызовет новый запрос для обновления кэша. Все компоненты, которые подписаны на это состояние, будут перерисованы</li>

37 </ul>Это только некоторые свойства, но уже их будет достаточно для большинства задач.

38 Для builder.mutation() хук выглядит несколько сложней:

39 Такие хуки уже возвращают массив. Первый элемент массива - это функция, с помощью которой мы можем вызывать запрос. А второй элемент - уже знакомый нам объект, через который мы можем отслеживать состояние запроса. Как видите, каждый хук предоставляет свое состояние для каждого запроса. Это позволяет не писать однотипный код и вручную заполнять состояние и отслеживать процессы.

40 Благодаря тому, что RTK Query использует кэш, при использовании множества одинаковых хуков, происходит только один запрос на сервер. Кэш сохраняется вместе с параметрами. Например, для запросов /user/1 и /user/2 будут созданы разные кэши

41 <h2>Функция запроса</h2>

42 RTK Query позволяет полностью заменить способ отправки запроса. Для этого используется свойство queryFn. В него передается функция, которая возвращает данные:

43 Это может потребоваться, например, чтобы заменить http-клиент.

44 <h2>Теги</h2>

45 Частая задача, когда данные зависят от других данных. Например, мы удаляем пользователя, сервер при этом удаляет все сообщения этого же пользователя. Теперь список сообщений в приложении считается устаревшим, так как может содержать сообщения удаленного пользователя. В RTK Query для такой задачи используется механизм тегов. Каждый эндпоинт мы можем пометить одним или несколькими тегами. В тех эндпоинтах, где происходит изменение состояния, мы отмечаем теги, которые зависят от изменяемого состояния. Разберем пример:

46 В примере выше для эндпоинтов getUsers и getComments задан тег User с помощью свойства providesTags, в него передается список тегов. Для эндпоинта removeUser передан этот же тег User в свойство invalidatesTags. Теперь, когда будет происходить запрос на удаления пользователя, RTK Query инвалидирует указанные теги. Это значит, что все кэши эндпоинтов с заданным тегом будут помечены как устаревшие, и данные будут загружены повторно. В нашем случае это будут эндпоинты getUsers и getComments.

47 Теги могут содержать уникальную информацию:

48 В примере выше теги формируются с помощью функций. Каждая функция возвращает объект вида { type, id }. Это позволяет манипулировать кэшами отдельных сущностей. Например, при обновлении пользователя с конкретным id, эндпоинт getUser обновит данные этого пользователя, но кэши остальных пользователей останутся без изменений.