React Query usage
React Query предоставляет удобный способ написания запросов в API через react hooks.
Директории. Наименования.В директории src/api/ создаются папки, название которых должно соответствовать названию домена API. Обычно домен прописывается вначале метода, например, методGET /catalog/banners:search
соответствует домену catalog
(строго говоря, домен называется PIM, но для удобства единообразия неймингов на фронте и бэке, примем более часто повторяющееся название домена). Наименование файла должно семантически отражать описываемые в нем методы. Например, файл banners.ts
содержит методы для CRUD баннера/ов#
Структураapi → apiDomainName → method.ts
В директории apiDomainName также есть папка с типами. Типы описываются согласно предоставляемой бекендерами документации в Swagger’е.
Все методы реэкспортируются в файлике index.ts
. Для удобства импортов в места использования. Аналогично и с типами.
Например в types/index.ts
будет примерно такой код
#
Написание хуковЗдесь не должно быть проблем, все дается просто по аналогии с другими примерами.
Не забывать прописывать все типы: для ответа, для ошибки, для параметров (если есть)
👍
Для хуков, использующих useQuery
, не забывать прокидывать параметры в ключ queryKey
Иначе, мы не получим прелести автоматического рефетча при изменении параметров.
Также, считаю хорошей практикой, прописав параметр BrandsParams, не разворачивать его так, как это сделано в примере ниже. А делать это по месту использования хука. Потому что разные наборы параметров могут быть необходимы в разных условиях (и судя по swagger'у здесь представлены не все)
💩
#
Пример использования хука мутацииОпределим сам хук
Добавим хук на страницу.
И используем метод mutateAsync
Обратите внимание, константа createProductGroupBanner – это объект. Но здесь мы не будем использовать деструктуризацию, для того, чтобы не заниматься бесконечным переименованием в случае использования других хуков мутации на одной странице. Например
💩
#
Инвалидация кеша.После использования хука мутации, а именно удаления/обновления/добавления какой-нибудь сущности, то нужно инвалидировать кеш и переполучить данные либо для конкретной сущности, либо для всего списка сущностей. Можно сделать оптимистичное обновление интерфейса и в случае неудачи откатиться назад, но это немного сложно, и на мой взгляд, для этого проекта избыточно.
Сейчас на проекте встречается 2 способа инвалидации кэша:
Первый. После успешной мутации мы скидываем кеш для конкретных ключей. В примере ниже, кэш станет невалидным для всех ключей, начинающихся с 'brands'. Это действие произойдет автоматически.Какой из двух способов использовать, решать вам. Но помните, что в первом случае инвалидация кеша и приведет к переполучению всех данных, чей ключ прокинут в invalidateQuery(key)
. И это будет происходить всякий раз при мутации.