Posted:
Апр 19, 2023
Comments:
0 Comments

Ключ запроса: Подключение с помощью ключей API — Azure Cognitive Search

Содержание

Подключение с помощью ключей API — Azure Cognitive Search


  • Статья




Когнитивный поиск предлагает проверку подлинности на основе ключей, которую можно использовать при подключениях к службе поиска. Ключ API — это уникальная строка, состоящая из 52 случайных чисел и букв. Запрос, сделанный к конечной точке службы поиска, будет принят, если оба запроса и ключ API действительны.

Примечание

Краткое примечание о том, как терминология «ключ» используется в Когнитивном поиске. Ключ API, описанный в этой статье, относится к ИДЕНТИФИКАТОРу GUID, используемому для проверки подлинности запроса. Отдельный термин «ключ документа» относится к уникальной строке в индексируемом содержимом, которая используется для уникальной идентификации документов в индексе поиска.

Типы ключей API

Существует два типа ключей, используемых для проверки подлинности запроса:

ТипУровень разрешенийМаксимумКак было создано
АдминистративныйПолный доступ (чтение и запись) для всех операций с содержимым2 1При создании службы генерируются два ключа администратора, которые на портале называются первичным и вторичным. При необходимости их можно создать заново независимо друг от друга.
ЗапросДоступ только для чтения, ограниченный коллекцией документов индекса поиска50Служба создает один ключ запроса. Администратор службы поиска может создать дополнительные сведения по запросу.

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

Визуально нет различий между ключом администратора или ключом запроса. Оба ключа представляют собой строки, состоящие из 52 буквенно-цифровых символов, создаваемых случайным образом. Если вы не знаете, какой тип ключа указан в приложении, вы можете проверить значения ключа на портале.

Использование ключей API для подключений

Ключи API используются для запросов плоскости данных (содержимого), таких как создание или доступ к индексу или любой другой запрос, представленный в REST API поиска. При создании службы ключ API является единственным механизмом проверки подлинности для операций плоскости данных, но вы можете заменить или дополнить проверку подлинности с помощью ролей Azure , если не удается использовать жестко заданные ключи в коде.

Ключи API указываются в клиентских запросах к службе поиска. Передача допустимого ключа API в запрос считается подтверждением запроса от авторизованного клиента. Если вы создаете, изменяете или удаляете объекты, вам потребуется ключ API администратора. В противном случае ключи запросов обычно распространяются среди клиентских приложений, которые выдают запросы.

Ключи API можно указать в заголовке запроса для вызовов REST API или в коде, который вызывает клиентские библиотеки azure.search.documents в пакетах SDK Для Azure. Если вы используете портал Azure для выполнения задач, назначение ролей определяет уровень доступа.

Ниже приведены рекомендации по использованию жестко заданных ключей в исходных файлах.

  • Во время ранней разработки и проверки концепции, когда безопасность слабее, используйте образцы или общедоступные данные.

  • Для зрелых решений или рабочих сценариев переключитесь на Azure Active Directory и доступ на основе ролей , чтобы исключить необходимость в жестко заданных ключах. Или, если вы хотите продолжать использовать ключи API, обязательно отслеживайте, кто имеет доступ к ключам API , и регулярно создавайте ключи API .

  • Портал
  • PowerShell
  • Use the Application Insights REST API to build custom solutions (Использование интерфейса REST API Application Insights для создания пользовательских решений)
  • C#

Проверка подлинности по ключу встроена, поэтому никаких действий не требуется. По умолчанию портал использует ключи API для автоматической проверки подлинности запроса. Однако при отключении ключей API и настройке назначений ролей портал использует назначения ролей.

В Когнитивном поиске большинство задач можно выполнять в портал Azure, включая создание объектов, индексирование с помощью мастера импорта данных и запросы через обозреватель поиска.

Примечание

В целях безопасности в URI запроса не рекомендуется передавать конфиденциальные данные, например api-key. По этой причине Когнитивный поиск Azure принимает в строке api-key запроса только ключ запроса. Как правило, мы рекомендуем передавать api-key в заголовке запроса.

Разрешения на просмотр ключей API и управление ими

Разрешения на просмотр ключей API и управление ими передаются через назначения ролей. Просматривать и повторно создавать ключи могут участники следующих ролей:

  • Владелец
  • Участник
  • Участник службы поиска
  • Администратор и соадминистратор (классическая модель)

Следующие роли не имеют доступа к ключам API:

  • Читатель
  • Участник данных индекса поиска
  • Читатель данных индекса поиска

Поиск существующих ключей

Можно просматривать ключи API и управлять ими на портале Azure или с помощью PowerShell, Azure CLI или REST API.

  • Портал
  • PowerShell
  • Azure CLI
  • Use the Application Insights REST API to build custom solutions (Использование интерфейса REST API Application Insights для создания пользовательских решений)

  1. Войдите в портал Azure и найдите службу поиска.

  2. В разделе Параметры выберите Ключи для просмотра ключей администратора и запросов.

Создание ключей запросов

Ключи запросов используются для доступа к документам только для чтения в индексе для операций, предназначенных для коллекции документов. Запросы поиска, фильтрации и предложений — это все операции, для которых используется ключ запроса. Для выполнения любой операции только для чтения, которая возвращает системные данные или определения объектов, такие как определение индекса или состояние индексатора, требуется ключ администратора.

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

  • Портал
  • PowerShell
  • Azure CLI
  • Use the Application Insights REST API to build custom solutions (Использование интерфейса REST API Application Insights для создания пользовательских решений)

  1. Войдите в портал Azure и найдите службу поиска.

  2. В разделе Параметры выберите Ключи , чтобы просмотреть ключи API.

  3. В разделе Управление ключами запросов используйте ключ запроса, уже созданный для службы, или создайте новые ключи запросов. Ключ запроса по умолчанию не называется, но другие созданные ключи запроса могут быть названы для управляемости.

Повторное создание ключей администратора

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

  1. В разделе Параметры выберите Ключи, а затем скопируйте вторичный ключ.

  2. Во всех приложениях обновите параметры, добавив вторичный ключ в качестве ключа API.

  3. Заново создайте первичный ключ.

  4. Обновите все приложения, указав новый первичный ключ.

Если непреднамеренно повторно создать оба ключа одновременно, все клиентские запросы, использующие эти ключи, завершатся ошибкой HTTP 403 Forbidden. Однако содержимое не удаляется, и вы не заблокированы навсегда.

Вы по-прежнему можете получить доступ к службе через портал или программным способом. Функции управления работают через идентификатор подписки, а не ключ API службы, и, таким образом, по-прежнему доступны, даже если ключи API не являются.

После создания новых ключей с помощью портала или уровня управления доступ к содержимому (индексы, индексаторы, источники данных, карты синонимов) восстанавливается после предоставления этих ключей в запросах.

Обеспечение безопасности ключей API

Используйте назначения ролей, чтобы ограничить доступ к ключам API.

Обратите внимание, что для шифрования ключей API невозможно использовать шифрование ключей, управляемых клиентом . Только конфиденциальные данные в самой службе поиска (например, содержимое индекса или строки подключения в определениях объектов источников данных) могут быть зашифрованы с помощью CMK.

  1. Перейдите к странице своей службы поиска на портале Azure.

  2. В области навигации слева выберите Управление доступом (IAM) , а затем вкладку Назначение ролей.

  3. В фильтре Роли выберите роли, которые имеют разрешение на просмотр ключей или управление ими (владелец, участник, участник службы поиска). Итоговые субъекты безопасности, назначенные этим ролям, имеют разрешения ключа в службе поиска.

  4. В качестве меры предосторожности также перейдите на вкладку Классические администраторы , чтобы определить, есть ли у администраторов и соадминистров доступ.

См. также

  • Безопасность Когнитивного поиска Azure
  • Управление доступом на основе ролей Azure в Когнитивном поиске Azure
  • Управление с помощью PowerShell

4 оригинальные тактики подбора ключей на русском (+3 для ключей на английском) – PR-CY Блог

Способы найти перспективные запросы для SEO, настройки рекламы и идей контента, которые мало кто использует. Обновленный материал.

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

Часть из этих методов придумал и протестировал эксперт в SEO Глен Оллсопп. Мы перевели и адаптировали его материал. Способы не элементарные, зато бесплатные.

1. Найти запросы, по которым молодые сайты смогли выйти в топ

Логика такая: если молодые сайты легко попали в топ по каким-то частотным запросам, нужно узнать эти запросы и использовать для продвижения своего проекта. Молодые сайты не успели нарастить ссылки и авторитет, значит, выбились в топ за счет SEO и контента, а в этом вы можете посоревноваться.

Собрать сайты из топов можно вручную или любым парсером. Что нужно делать:

  1. Составить список из нескольких десятков ключевых слов в вашей нише с 500-5000 запросами в месяц, спарсить выдачу.

  2. Скопировать в таблицу сайты с первых двух страниц выдачи по этим ключам.

  3. Найти среди них молодые домены. Проверить возраст можно, к примеру, на сайте Whois. com.

  4. Посмотреть, сколько трафика они получают и по каким еще запросам хорошо ранжируются, выбрать для себя интересные запросы и страницы, которые по ним ранжируются.

  5. Сделать контент лучше: полезнее, новее и релевантнее, чем у них в топе.

Для сбора сайтов вручную придется потратить много времени, быстрее будет с парсерами. Есть бесплатный Анализ топа выдачи, он выведет список URL из топа по нужному запросу.

Сбор URL из топ-20

Определить, под какие запросы оптимизированы сайты, можно с помощью другого инструмента. Он определяет 200 ключевых слов конкурентов и сортирует их по позиции или числу показов. Он бесплатный. Если вы пользуетесь тарифами основного Анализа сайта, то этот инструмент покажет число показов, позиции и URL. Если не пользуетесь, то просто отобразит ключи.

Просмотр запросов

Если у новых сайтов получилось занять топ по этим частотным запросам, то и у вас получится. Особенно если ваш сайт авторитетнее и старше.

2. Потеснить из топа сайты, которые там не должны быть

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

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

Гленн поделился примером из ниши макияжа. Один из самых популярных сайтов в индустрии — MakeupTalk. Гленн анализировал, какие страницы сайта показывают лучший рейтинг. В то время это была страница, которая высоко ранжировалась по запросу «is ipsy worth it».

Анализ топиков форума

В этой теме несколько лет ничего не писали. Люди, которые искали «is ipsy worth it», хотели узнать, стоит ли своих денег подписка на бьюти-боксы Ipsy. Сейчас эта страница ничем не могла им помочь: за несколько лет сервис мог стать лучше или хуже. Для поисковика новый контент был бы намного ценнее. Сейчас в 2021 году выдачу заполнили свежие материалы.

Раз поисковики стремятся выдавать пользователям актуальный контент, вы можете предоставить им свой взамен устаревшего. Есть много привязанных к датам ключей, под такие запросы можно создавать и оптимизировать страницы на своем сайте и каждый год их обновлять.

Интересное по теме:
Как найти ключи благодаря опросу пользователей
6 важных мыслей из 10-летнего опыта написания SEO-статей

3. Посмотреть хвосты запросов не только в ПС

Многие используют подсказки Google или Яндекс при вводе запроса, чтобы получить варианты популярных запросом с длинным хвостом.

Примеры хвостов из подсказок

Хвосты можно собрать не только в поисковиках, но и на других площадках: YouTube, Pinterest, Aliexpress, Ozon, Bing и прочих.

Использование нескольких площадок дает большую вариативность запросов и больше идей. К примеру, подсказки в YouTube отличаются от того, что предлагает Google.

Вариант хвостов на YouTubeВариант хвостов в Google

В YouTube можно посмотреть, что стало самым востребованным у конкурентов, и попытаться сделать более актуальный контент. Для этого нужно перейти на канал конкурента, открыть вкладку Видео и отсортировать по популярности.

Сортировка по самым популярным

Если популярные ролики были слишком давно и темы объективно устарели, просто посмотрите, что лучше всего заходит аудитории в последние несколько месяцев.

В Pinterest тоже можно увидеть окончания запросов, отличные от того, что предлагают Google и Яндекс.

Примеры запросов в Pinterest

4. Взять идеи из Google Images и Яндекс.Картинок

Идея простая: вы делаете запрос в разделе поиска по картинкам в Google или Яндексе, а поисковики вместе с результатом предлагают теги, которые кажутся им самыми близкими к тому, что вы ввели. Объедините их с запросом, который вы ввели. Получатся идеи для блога, материалов для рассылки, подарков пользователям в качестве бонуса за подписку.

Теги от Яндекса и Google

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

Что делать с ключами дальше? Всю собранную семантику для сайта нужно разбить на кластеры и заняться проектированием страниц.

Бонус: идеи для англоязычных запросов

5. Использовать сервисы для просмотра запросов пользователей

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

  • QuestionDB — укажите общее название темы на английском, например, copywriting, и сервис выдаст запросы с этим ключом или вопросы от пользователей.

Примеры запросов по теме «beauty box»

  • Answer The Public — делает то же самое, но предлагает результаты, разделенные по видам запроса: «почему», «как сделать» и так далее. Бесплатно можно посмотреть два запроса в день. С русским языком работает, но плохо.

Пример списка запросов по теме «link building»

6. Изучить горячие обсуждения в Reddit

Reddit — популярная на западе платформа обсуждений. Интересные запросы для любой ниши могут подсказать темы обсуждений — сабреддиты.

У Reddit есть инструмент, который показывает самые популярные темы, о которых говорят люди — Reddit Keyword Research Tool. Нужно добавить в инструмент сабреддит, а он выдаст список ключевых слов, о которых говорят в этом конкретном разделе.

Пример использования, ключи из сабреддита «boardgames»

У каждого ключа будет ссылка на сообщение, поясняющее контекст употребления, и данные об объеме поиска за месяц из Планировщика ключевых слов Google.

7. Посмотреть ключи с помощью пользовательского поиска Google (Google Custom Search Engine)

Для тех, кто использует сервис Google Custom Search Engine — систему персонального интернет-поиска. Владельцы сайтов устанавливают систему на своем сайте и настраивают область поиска по всему интернету или по определенному списку сайтов.

С его помощью можно найти своих конкурентов и новые идеи. К примеру, взять несколько хороших блогов о дизайне, добавить их в систему Google Custom Search Engine и увидеть, на какие ключевые запросы сайты ориентируются в этом месяце. Эти идеи контента можно использовать в своем блоге.

Запрос в Google Custom Search Engine

В зависимости от сайтов, которые отслеживаете, и ниши, вы можете найти информацию о прямых конкурентах по таким запросам:

  • «intitle: giveaway» выведет страницы с отзывами аудитории;

  • «last modified» либо «updated on» с датой покажут старый контент, который обновили;

  • «we interviewed», чтобы найти специалистов на интервью, готовых к диалогу.

Суть тактики в том, что не искать результаты по всему интернету, а отслеживать нужные ключи только по сайтам конкурентов.

Как настроить Google Custom Search Engine

Откройте Функции поиска — Дополнительно:

Настройка

В этом окне можно настроить сортировку по ключам из карты сайта, разметки сниппетов или метатегов.

Если работаете в сфере, где покупатели охотно делятся мнением о продукте, можно настроить ключ для поиска страниц по количеству полученных отзывов. Так вы определите, какие товары востребованы в первую очередь и что стоит рекламировать.

Ключ для отзывов

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

Результаты с отзывами

Несколько других ключей:

  • «review-RatingCount» — ключ для поиска отзывов в рейтинге;

  • «metatags-DateModified» — поиск по метатегам;

  • «itemprop-DateModified» — поиск по разметке;

Если добавляете сайты вручную, соберите достаточно большую базу, чтобы результаты были полезными.

Еще по теме:
как Google Trends поможет работать с ключами

Что делать с ключами дальше? Всю собранную семантику для сайта нужно разбить на кластеры, об этом у нас есть подробная статья.

Расскажите в комментариях, как вам эти способы поиска ключей, какие вы пробовали?

эффективных ключей запроса React | Блог Tkdodo

Фото Chunli JU

Последнее обновление: 23.04.2022

  • #1: Практический запрос React
  • #2: Данные React Query. Проверка статуса в React Query
  • #5: Тестирование React Query
  • #6: React Query и TypeScript
  • #7: Использование WebSockets с React Query
  • #8: Эффективные ключи React Query
    • #8a: Использование контекста функции запроса
  • #9: Заполнитель и исходные данные в React Query
  • #10: React Query в качестве диспетчера состояний : Освоение мутаций в React Query
  • #13: Автономный React Query
  • #14: React Query и формы
  • #15: Часто задаваемые вопросы по React Query
  • #16: React Query и React Router
  • #17: Заполнение кэша запросов
  • #18: Внутри React Query
  • #19: Типобезопасный React Query
  • 한국어
  • Добавить перевод

Ключи запроса — очень важная основная концепция в React Query. Они необходимы для того, чтобы библиотека могла правильно кэшировать ваши данные и автоматически обновлять их при изменении зависимости от вашего запроса. Наконец, это позволит вам взаимодействовать с кэшем запросов вручную, когда это необходимо, например, при обновлении данных после мутации или когда вам нужно вручную аннулировать некоторые запросы.

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

Кэширование данных

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

Самое главное, ключи должны быть уникальными для ваших запросов. Если React Query найдет запись для ключа в кеше, он будет использовать ее. Также имейте в виду, что вы не можете использовать один и тот же ключ для useQuery и useInfiniteQuery . Ведь есть только один Query Cache, и вы бы разделили данные между этими двумя. Это нехорошо, потому что бесконечные запросы имеют принципиально иную структуру, чем «обычные» запросы.

не смешивать ключи

 
 1useQuery({ queryKey: ['todos'], queryFn: fetchTodos }) 
 
 2 
 
 3// 🚨 это не сработает '], queryFn: fetchInfiniteTodos }) 
  
 5 
  
 6// ✅ choose something else instead 
  
 7useInfiniteQuery({ 
  
 8  queryKey: ['infiniteTodos'], 
  
 9  queryFn: fetchInfiniteTodos, 
  
 10})

Автоматическая повторная выборка

Запросы являются декларативными.

Это очень важная концепция, которую невозможно подчеркнуть в достаточной мере, а также то, что может занять некоторое время, чтобы «щелкнуть». Большинство людей думают о запросах, и особенно о повторной загрузке, императивным способом.

У меня есть запрос, он извлекает некоторые данные. Теперь нажимаю эту кнопку и хочу перепрошить, но с другими параметрами. Я видел много попыток, которые выглядели так:

императив-редактировать

 
 1function Component() { 
 
 2 const { data, refetch } = useQuery({ 
 
 3 queryKey: ['todos'], 
 
 4 queryFn: fetchTodos, 
 
 5 }) 
 
 6 
 
 7 // как передать параметры для обновления ❓ 
 
 8 return  refetch(???)} /> 
 
 9}

Ответ: Нет.

refetch не для этого, а для перезагрузки с теми же параметрами .

Если у вас есть состояние , которое изменяет ваши данные, все, что вам нужно сделать, это поместить его в ключ запроса, потому что React Query будет автоматически запускать повторную выборку при изменении ключа. Поэтому, когда вы хотите применить свои фильтры, просто измените состояние клиента :

query-key-drives-the-query

 
 1function Component() { 
 
 2 const [filters, setFilters] = React. useState( ) 
 
 3 const {данные} = useQuery({ 
 
 4 queryKey: ['todos', фильтры], 
 
 5 queryFn: () => fetchTodos(filters), 
 
 6 }) 
 
 7 
 
 8 // ✅ установить локальное состояние и позволить ему «управлять» запросом 
 
 9 return  
 
 10}

Повторный рендеринг, вызванный обновлением setFilters , передаст другой ключ запроса в React Query, что приведет к повторной выборке. У меня есть более подробный пример в № 1: Практический запрос React — относитесь к ключу запроса как к массиву зависимостей.

Взаимодействия вручную

Взаимодействия вручную с кэшем запросов наиболее важны для структуры ваших ключей запросов. Многие из этих методов взаимодействия, такие как invalidateQueries или setQueriesData, поддерживают фильтры запросов, которые позволяют вам нечетко сопоставлять ваши ключи запросов.

Эффективные ключи запроса React

Обратите внимание, что эти пункты отражают мое личное мнение (как и все в этом блоге), поэтому не воспринимайте это как то, что вам абсолютно необходимо делать при работе с ключами запроса. Я обнаружил, что эти стратегии лучше всего работают, когда ваше приложение становится более сложным, и они также достаточно хорошо масштабируются. Вам определенно не нужно делать это для приложения Todo 😁.

Совместное размещение

Если вы еще не читали книгу Кента Доддса «Обслуживание посредством совместного размещения», прочтите ее. Я не верю, что глобальное хранение всех ваших ключей запросов в /src/utils/queryKeys.ts улучшит ситуацию. Я храню свои ключи запросов рядом с соответствующими запросами, расположенными в каталоге функций, например:

 
 1- src 
 
 2 - функции 
 
 3 - Профиль 
 
 4 - index.tsx 
 
 5 - запросы.ts 
 
 6 - Todos 
 
 7 - index.tsx 
 
 8 - query.ts

Файл запросов будет содержать все, что связано с React Query. Обычно я экспортирую только пользовательские хуки, поэтому фактические функции запросов, а также ключи запросов останутся локальными.

Всегда использовать ключи массива

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

always-use-array-keys

 
 1// 🚨 в любом случае будет преобразовано в ['todos'] 
 
 2useQuery({ queryKey: 'todos' }) 
 
 3// ✅ 
 
 4useQuery({ queryKey: ['todos'] })

Обновление : в React Query v4 все ключи должны быть массивами.

Структура

Структурируйте свои ключи запроса от наиболее общего до наиболее конкретного с любым количеством уровней детализации, которые вы считаете нужным между ними. Вот как я бы структурировал список дел, который позволяет фильтровать списки, а также подробные представления:

 
 1['todos', 'список', {фильтры: 'все'}] 
 
 2['todos', 'список', {фильтры: 'сделано'}] 
 
 3['todos', ' detail', 1] 
 
 4['todos', 'detail', 2]

С помощью этой структуры я могу аннулировать все todo, связанные с ['todos'] , все списки или все детали, как а также настроить таргетинг на один конкретный список, если я знаю точный ключ. Обновления ответов на мутации
Станьте более гибкими, потому что при необходимости вы можете настроить таргетинг на все списки:

обновления-из-ответов-мутаций

 
 1function useUpdateTitle() { 
 
 2 return useMutation({ 
 
 3 MutationFn: updateTitle, 
 
 4 onSuccess: (newTodo) ⅅ { 
 
 деталь задачи 
 
 6 queryClient.setQueryData(['todos', 'detail', newTodo.id], newTodo) 
 
 7 
 
 8 // ✅ обновить все списки, содержащие эту задачу 
 
 9 queryClient.setQueriesData([ 'todos', 'список'], (предыдущий) => 
 
 10 предыдущая.map((todo) => (todo.id === newTodo.id ? newTodo : todo)) 
 
 11 ) 
 
 12 }, 
 
 13 }) 
 
 14} 
 04 04 04  может не работать, если структура списков и детали сильно различаются, поэтому в качестве альтернативы вы также можете, конечно, просто аннулировать все списки: { 
 
 3 мутацияFn: updateTitle, 
 
 4 onSuccess: (newTodo) => { 
 
 5 queryClient.setQueryData(['todos', 'detail', newTodo. id], newTodo) 
 
 6 
 
 7 // ✅ просто аннулировать все списки 
 
 8 queryClient.invalidateQueries({ queryKey: ['todos', 'list'] }) 
 
 9 }, 
 
 10 }) 
 
 11}

Если вы знаете, в каком списке вы сейчас находитесь, например, читая фильтры из URL-адреса и, следовательно, создавая точный ключ запроса, вы также можете комбинировать эти два метода и вызывать setQueryData в вашем списке и сделать недействительными все остальные:

Combine

 
 1function useUpdateTitle() { 
 
 2 // представьте пользовательский хук, который возвращает текущие фильтры, 
 
 3 // хранится в URL 
 
 4 const { фильтры } = useFilterParams() 
 
 5 
 
 6 return useMutation({ 
 
 7 MutationFn: updateTitle, 
 
 8 onSuccess: (newTodo) => { 
 
 9 queryClient.setQueryData'(['todos ', newTodo.id], newTodo) 
 
 10 
 
 11 // ✅ мгновенно обновить список, в котором мы сейчас находимся 
 
 12 queryClient. setQueryData(['todos', 'list', { фильтры }], (previous) => 
 
 13 previous.map( (todo) => (todo.id === newTodo.id ? newtodo : todo)) 
 
 14 ) 
 
 15 
 
 16 // 🥳 сделать недействительными все списки, но не обновлять активный 
 
 17 queryClient.invalidateQueries({ 
 
 18 queryKey: ['todos', 'список'], 
 
 19 Refetchactive: False, 
 
 20}) 
 
 21}, 
 
 22}) 
 
 23}

Обновление : в V4, Refetchactive был заменен на Refetchtype . В приведенном выше примере это будет refetchType: 'none' , потому что мы не хотим ничего обновлять.

Использовать фабрики ключей запросов

В приведенных выше примерах вы можете видеть, что я много раз объявлял ключи запросов вручную. Это не только чревато ошибками, но и затрудняет внесение изменений в будущем, например, если вы обнаружите, что хотите добавить еще уровень детализации ваших ключей.

Вот почему я рекомендую одну фабрику Query Key для каждой функции. Это всего лишь простой объект с записями и функциями, которые будут создавать ключи запроса, которые вы затем можете использовать в своих пользовательских хуках. Для приведенной выше структуры примера это будет выглядеть примерно так:

query-key-factory

 
 1const todoKeys = { 
 
 2 all: ['todos'] as const, 
 
 3 lists: () => [ ...todoKeys.all, 'список'] как const, 
 
 4 список: (фильтры: строка) => [...todoKeys.lists(), { фильтры }] as const, 
 
 5 детали: () => [...todoKeys.all, 'detail'] as const, 
 
 6 detail: (id: number) => [...todoKeys.details(), id] as const, 
 
 7}

Это дает мне большую гибкость, так как каждый уровень основывается на поверх другого, но по-прежнему доступен независимо:

examples

 
 1// 🕺 удалить все, что связано с функцией todos 
 
 2queryClient.removeQueries({ queryKey: todoKeys.all }) 
 
 3 
 
 4 // 🚀 🚀 Допустить признание всех списков 
 
 5QueryClient.InvalidateQueries ({QueryKey: todokeys. Lists ()}) 
 
 6 
 
 7 // 🙌 Предварительный 
 9 queryKey: todoKeys.detail(id), 
 
 10 queryFn: () => fetchTodo(id), 
 
 11})

На сегодня все. Не стесняйтесь обращаться ко мне в твиттере
если у вас есть какие-либо вопросы, или просто оставьте комментарий ниже. ⬇️

Нравится моноширинный шрифт в блоках кода?

Проверить monolisa.dev

az search query-key | Microsoft Узнайте

Твиттер

LinkedIn

Фейсбук

Электронная почта

  • Артикул

Управление ключами запросов поиска Azure.

Команды

az search query-key создать

Создает новый ключ запроса для указанной службы поиска.

az search query-key удалить

Удаляет указанный ключ запроса.

az поисковый запрос-ключ список

Возвращает список ключей API запросов для данной службы Azure Cognitive Search.

az search query-key create

Edit

Создает новый ключ запроса для указанной службы поиска.

Для каждой службы можно создать до 50 ключей запросов.

 Ключ поискового запроса az create --name
                           --ресурс-группа
                           --service-имя

Обязательные параметры

—name -n

Имя ключа запроса.

—resource-group -g

Имя группы ресурсов. Вы можете настроить группу по умолчанию, используя az configure --defaults group= .

—service-name

Имя службы поиска.

Глобальные параметры

—debug

Увеличить уровень детализации журнала, чтобы отображались все журналы отладки.

—help -h

Показать это справочное сообщение и выйти.

—only-show-errors

Показывать только ошибки, подавляя предупреждения.

—output -o

Формат вывода.

—query

Строка запроса JMESPath. См. http://jmespath.org/ для получения дополнительной информации и примеров.

—subscription

Имя или идентификатор подписки. Вы можете настроить подписку по умолчанию, используя набор учетных записей az -s NAME_OR_ID .

—verbose

Увеличить детализацию журнала. Используйте —debug для полных журналов отладки.

az search query-key delete

Редактировать

Удаляет указанный ключ запроса.

В отличие от ключей администратора, ключи запроса не генерируются повторно. Процесс повторного создания ключа запроса заключается в его удалении и повторном создании.

 ключ запроса поиска az удалить --ключ-значение
                           --ресурс-группа
                           --service-name

Обязательные параметры

—key-value

Значение ключа запроса.

—группа ресурсов -g

Имя группы ресурсов. Вы можете настроить группу по умолчанию, используя az configure --defaults group= .

—service-name

Имя службы поиска.

Глобальные параметры

—debug

Увеличить уровень детализации журнала, чтобы отображались все журналы отладки.

—help -h

Показать это справочное сообщение и выйти.

—only-show-errors

Показывать только ошибки, подавляя предупреждения.

—выход -о

Формат вывода.

—query

Строка запроса JMESPath. См. http://jmespath.org/ для получения дополнительной информации и примеров.

—subscription

Имя или идентификатор подписки. Вы можете настроить подписку по умолчанию, используя набор учетных записей az -s NAME_OR_ID .

—verbose

Увеличить детализацию журнала. Используйте —debug для полных журналов отладки.

az search query-key list

Изменить

Возвращает список ключей API запроса для данной службы Когнитивный поиск Azure.

 список ключей поискового запроса az --resource-group
                         --service-name

Обязательные параметры

—resource-group -g

Имя группы ресурсов.

This entry was posted in Ключевые слова