Давным-давно…
Получение инфраструктуры — ключевой момент в любой кодовой базе, особенно если вы имеете дело с внешним интерфейсом, потому что большая часть, если не все, отображаемые данные извлекаются с сервера.
Существует множество отличных библиотек. , поддерживаемый широким сообществом, для React (или React Native), например, отличная и проверенная инфраструктура загрузки.
Именно это привело меня к использованию RTK (Redux ToolKit) Query.
ПРИМЕЧАНИЕ. Эта статья не является введением в RTK Query (вы можете начать здесь).
Кроме того, это относится и к React, но примеры были написаны с учетом React-Native. .
ПОЧЕМУ? 🤔
При написании компонента одной из основ является наполнение нашего пользовательского интерфейса полученными с сервера данными.
Помня об этом, я обнаружил, что снова и снова пишу один и тот же шаблон:
Ознакомьтесь с RN docs для приведенного выше примера.
Однако этого было недостаточно. Как только мне захотелось большего, например обработки ошибок или уведомления пользователя о загрузке экрана, мне пришлось добавить больше шаблонов или реорганизовать некоторую инфраструктуру.
И если я решу закодировать инфраструктуру, как насчет других механизмов, таких как повторить, прервать и кэшировать?
Кроме того, как насчет того, чтобы организовать этот процесс — не делать один и тот же вызов дважды, создавая зависимость между вызовами (например, POST/PUT/DELETE и GET)? Нужна более надежная инфраструктура.
Учитывая это, я хотел знать, есть ли что-то, что могло бы дать мне хотя бы эти возможности и сэкономить мне и моей команде время и код.
ЧТО (очевидно, запрос RTK)? 😬
В нашем приложении React Native (RN) мы используем библиотеку Redux-ToolKit (RTK) для управления состоянием (и не только).
Я прочитал о библиотеке и концепции React Query, которые мне очень понравились, и ждал подходящего момента, чтобы интегрировать их.
Погрузившись в документацию RTK, я обнаружил, что в ней есть та же концепция, которую я искал, и она называется RTK Query. (РТКК). RTKQ был представлен как часть RTK выпуск v1.6.0.
Таким образом, мы можем иметь RTKQ в той же библиотеке, которую мы уже используем, что сэкономит нам некоторый размер пакета (необходимый для React-Native) по сравнению с установкой React Query отдельно.
Так что же такое RTK Query на самом деле? И как это так помогло моей команде и мне?
В двух словах, это не просто индикация состояния запроса, у нас также есть механизм повторной попытки и прерывания, механизм кэширования, включая аннулирование кеша для зависимых вызовов API и многое другое.
КАК (пристегнуться)? 😎
Здесь я собираюсь описать распространенные способы использования, некоторые подводные камни и ловушки в RTK Query, надеюсь, сэкономив вам время на обработку неожиданного поведения и потенциальных ошибок в вашем приложении.
ПРИМЕЧАНИЕ. Эта часть разбита на несколько тем. Нашей первой темой будет «Крючки», и мы дадим ссылки на другие темы в конце этой.
Крючки 🪝
Этот волшебный. Вместо того, чтобы вручную писать хуки для каждой конечной точки, RTK Query генерирует их для вас автоматически, если вы используете метод createApi (тот, который вы импортируете из «@reduxjs/toolkit/query/react»).
Вот некоторые распространенные хуки, которые вы обычно используете: useQuery, useMutationQuery, useLazyQuery.
useQuery —вызывается сразу после монтирования компонента для запросов GET.
useMutationQuery —для запросов, изменяющих данные сервера, и запросов, отличных от GET (хотя вы также можете использовать GET).
useLazyQuery — инициирует запрос GET в контролируемое время (не сразу после монтирования).
Посмотрите полный хук Сравнение возможностей
Дополнения и подводные камни хуков:
- [Extra] selectFromResult (применяется к хукам useQuery/useMutationQuery/useLazyQuery)
Это важно, особенно если мы хотим оптимизировать наш компонент.
Мы вероятно, следует использовать его всякий раз, когда у нас есть вложенные фрагменты, и мы хотим выбрать из объекта результата (возвращенного из нашего хука запроса/мутации).
- [Подводный камень] isLoading vs isFetching (применяется к перехватчикам useQuery/useMutationQuery/useLazyQuery)
Обратите внимание, что isLoading имеет значение true, только если у нас нет кэшированных данных, тогда как isFetching представляет состояние запроса и истинно всякий раз, когда мы извлекаем данные. - [Extra] unwrap (применяется к перехватчикам useMutationQuery/useLazyQuery)
В случае, если мы хотим обработать необработанный обещанный запрос (например, обернуть ваш запрос в try/catch) , нам нужно развернуть оболочку RTKQ из предоставленной триггерной функции, которая обрабатывает другие вещи для вас, например, содержит выданную ошибку.
- [Дополнительно] fixedCacheKey (применяется к хуку useMutationQuery)
Извлечение с помощью хука мутации даст нам свежие данные с нашего сервера. Но что, если мы хотим поделиться этими полученными данными? Вот здесь и пригодится fixedCacheKey.
Одним из примеров может быть, если мы хотим поделиться результатами мутации между компонентами.
- [Pitfall/Extra] PreferenceCacheValue (применяется к хуку useLazyQuery)
Ленивые хуки извлекают свежие данные (не кэшированные), но если мы хотим использовать кэшированные данные, мы необходимо включить PreferenceCacheValue.
- [Дополнительно] отписаться (применяется ко всем хукам, кроме useQueryState usePrefetch)
Для каждой конечной точки RTKQ кэширует данные на основе ссылки количество подписок (подробнее читайте ниже).
При использовании хуков также получаем автоматическую отписку при размонтировании компонента. - Бонус [Pitfall/Extra] инициировать (не связанный с ловушками)
Это позволяет вам инициировать (например, отправить действие) вызов API (например, запрос или мутацию) извне (или внутри) компонент.
Вот несколько моментов, на которые следует обратить внимание:
(а) Это увеличивает счетчик ссылок конечной точки.
(б) В отличие от предоставленных хуков, вы должны отказаться от подписки самостоятельно.
В «КАК?» есть еще кое-что, но я чувствую, что это слишком много, чтобы переваривать на данный момент, поэтому мы разветвляемся для большего количества контента, чтобы продолжить эту часть.
Если вам нужна передышка (или нет), вот ссылки на другие темы, чтобы продолжить эту часть:
- Кэширование
- Обработка ошибок (скоро)
Краткое содержание
Надеюсь, эта статья помогла вам узнать немного больше о RTK Query или даже побудила вас использовать его (рекомендуется для тех, кто уже использует RTK в своем приложении) или аналогичные решения.
Если у вас есть какие-либо комментарии или вопросы, я буду рядом с разделом комментариев.
Спасибо и не стесняйтесь обращаться!
Ссылки: React-Native docs | Документы РТК-запроса
