Comments 21
Зачем мне React Query, когда есть RTK Query?
Спасибо за пример, и небольшое пояснение.
Смотря на то, какой именно код вы используете в своём примере, сугубо по моему личному мнению, есть подозрение, что данный пример сильно "притянут за уши". И, на основе личного опыта, есть вопрос: а почему нельзя использовать useEffect на каждое из состояний в отдельности?
Пояснение вопроса: у нас есть несколько состояний нашего условного компонента, и каждое состояние, по написанной логике, отвечает за определенное поведение компонента, и мне не очень понятно, почему по одному изменению пропса должны меняться все состояния в совокупности разом, если каждое из данных состояний должно порождать то или иное дальнейшее поведение. То есть: category -> порождает обновление ссылки -> ссылка порождает fetch -> результат ответа (response / catch) на запрос порождает изменение либо data с обнулением error, либо error с обнулением data -> наличие которых уже порождает изменение isLoading, что в свою очередь позволяет держать актуальные состояния и ошибки в текущем моменте, а не держать их из "прошлого".
Глядя в эти примеры, прихожу к выводу, что тут скорее напрашивается кастомный хук, нежели сторонняя библиотека.
эта статья для того чтобы вам захотелось попробовать React Query, внутри библиотеки ещё много крутых и полезных функций
Будет здорово, если будет продолжение с более продвинутыми примерами :)
Можете пожалуйста подсказать как закодировать такую логику:
- по сабмиту получаем данные из формы
- делаем три параллельных запроса, в каждом из которых свои данные формы
- по результату второго запроса - делаем или не делаем четвёртый запрос, в котором используем ответ первого запроса.
- если четвёртый запрос ок - показываем успех с данными из этого запроса-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?)
Вот наивная реализация. Специально спрятал useQuery в массив, чтобы было чуть проще проводить параллели.
const submitHandler = async (formData) => {
const responses = [
useQuery({
queryKey: '0',
queryFn: () => service1.fetchData(formData.fieldValue1),
}),
useQuery({
queryKey: '1',
queryFn: () => service2.fetchData(formData.fieldValue2),
}),
useQuery({
queryKey: '2',
queryFn: () => service3.fetchData(formData.fieldValue3),
}),
];
const data = useQuery({
queryKey: '3',
queryFn: () => service4.fetchData(response[0].data),
enabled: response[1].data?.isExistSomeData,
});
if (responses[1].data?.isExistSomeData) {
if (!data.isLoading) {
service5.showSuccess(data.data);
}
} else {
service5.showFailure();
}
};Однако, вызов showSuccess и showFailure ошибочно соседствуют рядом с декларативным подходом react-query, у этого кода могут быть проблемы.
вызов showSuccess и showFailure ошибочно соседствуют рядом с декларативным подходом
Специально для этого кейса у хука useQuery есть целых 3 параметра - onError, onSettled, onSuccess
Так useQuery - это ж хук.. разве он может быть внутри массива, или внутри функции submitHandler вообще?
Хуки внутри компонента могут располагаться везде, если последовательность их вызовов между рендерами постоянна. Ниже анти-пример, никогда так не пишите:
const BadComponent = () => {
const staff = [
getSomething({user: useUser()}),
useSomethingElse(useQuery({})),
];
return <>{useLayout(staff)}</>;
}А вот внутри submitHandler хуку не место.
Ну так а как реализовать логику submitHandler с помощью react-query?
Вам помогут "мутации": https://tanstack.com/query/latest/docs/framework/react/guides/mutations.
Я понимаю, что там очень богатое апи.. мутации, condition-query.. и т.д. поэтому и хочу увидеть как с помощью этой библиотеки обработать логику выше, при нажатии на кнопку в рамках какого-то jsx-компонента. Как это правильно делают люди??..)
Потому что по своему опыту - это делается ужасно.. и рекламируемый профит react-query/swr и подобных абсолютно не стоит того.. если даже нельзя описать обычную последовательность запросов сверху\вниз без всяких костылей. Вот и хочу сравнить.. скорее всего я просто не умею пользоваться.
Тут, кажется, фишка в том, что это довольно стандартный флоу, и писать под него каждый раз кастомный хук...
Почему вам необходим React Query