Comments 21
Я не понял почему сделан вывод что swr на больших проектах не применим.
Хотелось бы раскрытие вопроса применения react-query vs swr в next
SWR в свою очередь предоставляет только один хук —
useSWR
Нет. SWR предоставляет хук useSWRMutation. Чем он отличается от useMutation из react-query из статьи не очень понятно, если честно.
Было бы интересно сравнение с https://www.reatom.dev/package/async/ :)
Всё никак не пойму популярность этих reаct-query\swr. Какие-то слишком замудрённые, а рекламируемый профит так себе. Честно пробовал прикрутить к домашнему проекту, плюнул и отказался через час:
- обалдел когда увидел апи и кучу флажков, напрмиер, isFetching, isLoading, isIdle и куча тонкостей какой когда лучше использовать.
- обалдел когда попытался по сабмиту сделать три параллельных запроса, и потом по результату например второго из них нужно сделать\или не сделать четвёртый запрос. Оно меня отправляет в dependent-queries. Вместо async\await сверху вниз - код становится какой-то ужасный.. сплошные use.. use..
- не получается делать запросы вне jsx-компонента без use (у меня проект на mobx, поэтому вся логика в сторах, а реакт просто шаблонизатор). Оно конечно предлагает использовать queryClient.fetchQuery,но как я понял теряются многие рекламируемые плюшки.
Может всё-таки мало времени уделил.
Да причина популярности проста - упрощение работы с серверными данными. После хранения сервеных данных в редаксе это прям глоток воздуха.
обалдел когда увидел апи и кучу флажков...
В большинстве случаев достаточно использовать isLoading.
обалдел когда попытался по сабмиту сделать три параллельных запроса
Если речь про мутиции, то есть метод mutateAsync, который возвращает Promise и работает с async/await.
Оно конечно предлагает использовать queryClient.fetchQuery,но как я понял теряются многие рекламируемые плюшки.
Плюшки не теряются. queryClient.fetchQuery так же как и useQuery(собственно под капотом и вызывается .fetchQuery) сохраняет данные в кеше. Вызываем queryClient.fetchQuery вне компонента, внутри компонента имеем доступ к данным по ключу через useQuery.
Если речь про мутиции, то есть метод
mutateAsync, который возвращает Promise и работает с async/await.
Можете пожалуйста подсказать как закодировать такую логику:
- по сабмиту получаем данные из формы
- делаем три параллельных запроса, в каждом из которых свои данные формы
- по результату второго запроса - делаем или не делаем четвёртый запрос, в котором используем ответ первого запроса.
- если четвёртый запрос ок - показываем успех с данными из этого запроса-4
На обычноим js это получается просто и понятно:
const submitHandler = async (formData) => {
const responses = await Promise.all([
service1.fetchData(formData.fieldValue1),
service2.fetchData(formData.fieldValue2),
service3.fetchData(formData.fieldValue3),
]);
if (responses[1].isExistSomeData) {
const data = await service4.fetchData(responses[0]);
service5.showSuccess(data);
} else {
service5.showFailure();
}
};Как это будет выглядеть в jsx-компоненте с помощью react-query? У меня получается ужасно.)
const mutation1 = useMutation({
mutationFn: (value) => service1.fetchData(value),
})
const mutation2 = useMutation({
mutationFn: (value) => service2.fetchData(value),
})
const mutation3 = useMutation({
mutationFn: (value) => service3.fetchData(value),
})
const mutation4 = useMutation({
mutationFn: (value) => service4.fetchData(value),
})
const submitHandler = async (formData) => {
const responses = await Promise.all([
mutation1.mutateAsync(formData.fieldValue1),
mutation2.mutateAsync(formData.fieldValue2),
mutation3.mutateAsync(formData.fieldValue3)
]);
if (responses[1].isExistSomeData) {
const data = await mutation4.mutateAsync(responses[0]);
service5.showSuccess(data);
} else {
service5.showFailure();
}
};
Можно репу немного почесать и вытащить это всё в отдельный хук, что бы не перегружать компонент кодом.
Да и вообще в принципе не обязательно использовать мутиции, ваш вариант тоже рабочий и ничему не противоречи.
Никакой особой магии, которую зачем-то приписал автор, они не дают:
Мутации представляют собой специальные функции, которые выполняют запросы на сервер для изменения данных, и автоматически обновляют соответствующий кэш после успешного завершения мутации.
Нет там никаких магических обновлений кеша. Результат мутаций хранится в своём кеше и вообще никак не относится к кешу query(которые отдаются при использовании useQuery). Класть данные в кеш query нужно руками, что вполне выполнимо и вашим способом.
Ну, с появлением RTK-Query, вопрос: "Избавимся ли мы от Redux?" потерял свою актуальность.
Есть состояние запросов - RTK, SWR и т.п.
Есть состояние приложения - Redux, MobX и т.п.
Когда в проекте начинаются различаться эти вещи, избавиться от Redux и заменить его на React.useState, если ненадо шарить между компонентами запро с и React.Context или zustan (или другой stm) становится легче.
Раньше на проектах часто сваливави все состояния запросов в Redux и он становился ещё большей помойкой)
p.s. не везде всё клали в Redux)
Не очень понятно почему, все-таки, при большом проекте нужно использовать react-qury.
Я не понял, как он может заменить редакс, вы вероятно из тех кто кладет данные из бэка в стэйт менеджер?
React-query очень нишевая библиотека удобная только на проектах где нужно дернуть ручку и показать дынные. Если чуть более сложно то возникают все новые и новые приколы.
Она скорее не облегчает работу, а меняет ее. Синхронизировать работу хуков между собой то еще удовольствие, высок риск иметь неконсистентный результат. Плюс все еще нужен стор, а это уже 2 места хранения данных и новые риски не консистентности.
Так же жесткий биндинг кода к вьюшкам (посути начинаем писать код во вьюшках), а это уже антипаттерн. Проектов с кодом (бизнес логикой) в компонентах много и без этого, конечно, и как правило там лютый треш и гавнокод получается, даже если хотелось сделать "правильно". Зато потом можно статейки на хабре написать как героически командой перезжали пол года с либы на либу, с фреймворка на фреймворк.
Это нельзя назвать инструментами управления состояния. В первую очередь такого рода либы нужно для кеширования.
cпасибо за статью. но на самом деле контекст статьи в сравнение двух библиотек управления запросами. и финал был сделан на основе библиотеки управления состоянием приложения vs состоянием запроса)
ну и redux приплели зря - этот вопрос касается не только redux и т.п
А с чем комбинируете rtk-query или SWR в приложении ? Как я понимаю тут именно state для запросов и их обработки ? А если шарить данные между разными частями приложения ?
react-query vs SWR и избавимся ли мы от Redux?