Дополнительные возможности запроса RTK
24 мая 2022 г.Ранее я писал о RTK, в этом рассказе будут освещены другие подробности его использование.
Представьте, что нам нужно отображать одни и те же данные, но из разных ресурсов в зависимости от входящего значения параметра. В этом случае у нас будет компонент с двумя хуками, которые обрабатывают запросы и получают данные.
В основном представление API выглядит так:
```машинопись
экспортировать константу configApi = baseApi.injectEndpoints({
конечные точки: построить => ({
fetchConfigDetails: build.query
запрос: arg => /config-details,
transformResponse: (x: IResponse
ОбеспечиваетТеги: ['Детали конфигурации'],
fetchConfigRunDetails: build.query
запрос: arg => /${arg.id}/config-details,
transformResponse: (x: IResponse
ProvideTags: ['ConfigRunDetails'],
overrideExisting: правда,
Он имеет две конечные точки, и основное различие между ними заключается в аргументе «id», поэтому на самом деле ресурсы разные. Таким образом, кеш также будет другим: один для ==ConfigDetails== и один для ==ConfigRunDetails==.
Для пояснения того, откуда хуки берут свои имена, я приведу следующий пример:
```машинопись
экспортировать константу {
использованиеFetchConfigDetailsQuery,
использоватьFetchConfigRunDetailsQuery,
} = configApi;
Имя хука состоит из префикса use, имени конечной точки ==fetchConfigDetails== и постфикса типа запроса (функция, которая используется для создания конечной точки) build.query → ==useFetchConfigDetailsQuery==.
И эти два хука будут использоваться в одном компоненте:
```машинопись
const RowResultsDetails: React.FC
const {id} = useParams
const fetchDetails = useFetchConfigDetailsQuery(
пропустить: !!id,
selectFromResult: ({ data, isFetching }) => ({
isFetching: isFetching,
данные: selectConfigDetails(данные),
const fetchRunDetails = useFetchConfigRunDetailsQuery(
{ я бы },
пропустить: !id,
selectFromResult: ({ data, isFetching }) => ({
isFetching: isFetching,
данные: selectRunConfigDetails(данные),
const {данные, isFetching} = идентификатор? fetchRunDetails: fetchDetails;
возврат (
<дел>
Как вы, возможно, знаете, хуки в React должны иметь один и тот же порядок и не могут находиться внутри какого-либо условия «если еще». В RTK из-за такого ограничения есть специальное свойство «пропустить» непосредственно во втором параметре (опциях) хука. С помощью этой опции вы можете указать RTK выполнять или не выполнять хук. Кроме того, для оптимизации рендеринга RTK предоставляет возможность использовать библиотеку повторного выбора для выбора данных, которые вам нужны в этом конкретном компоненте. Другими словами, ==selectConfigDetails== и ==selectRunConfigDetails== — это селекторы для запоминания данных из кеша. Если запрос будет вызван, а выбранные данные не будут изменены, в компоненте ничего не произойдет.
Селектор на самом деле ничем не отличается от селектора магазина, за исключением того, что вы не предоставляете ему состояние.
```машинопись
const пустой массив = [];
экспортировать константу selectConfigDetails = createSelector(
(данные?: IConfig[]) => данные
(данные) => данные?.filter(c => c.isAvailable) ?? пустой массив
Важным моментом здесь является то, что если вы используете один и тот же селектор для обоих хуков, это вызовет избыточный повторный рендеринг. Другими словами, «селектор» уникален и запоминает результат. Для одного и того же селектора в результате будет два разных значения. Будьте осторожны, чтобы не перерисовывать компонент часто. Кроме того, если вы предпочитаете использовать хук ==useMemo== для запоминания данных, в этом сценарии должны быть два разных использования ==useMemo==.
Оригинал