3 правила использования React Query

Смотреть на 1.5x -- записывался в 5 утра)
В этом видео мы на примере туду листа посмотрим какие есть классические проблемы неправильного использования React query
Подписывайтесь на мой telegram канал:
t.me/cleanfrontend
Исходники:
codesandbox.io/s/proud-leftpa...

[@nullf192]

Круто, ждём ещё рекомендаций, и про removeQueies, invalidatQueries, видосик)

[@Ramosok]

Классное видео!

[@user-vm2db5cq1g]

Крутое видео!! а когда будут еще видео про реакт квери?))) очень актуальная тема для более глубокого изучения)

[@user-tt3bc7yk8r]

Спасибо, с радостью я бы посмотрел пример как юзать реактквкри с фильтром и дебаунсом для обновления фильтра

[@user-di3wg7yp4p]

Ощущение, будто пропустил какую-то вводную часть по react query))

[@constantin1693]

Классное видео! Было бы интересно подробнее узнать про react query + websicket, если по сокету приходят не запросы на инвалидацию, а новые данные (например чат)

[@paromovevg]

Моё скромное мнение что чат уже не для react-query задача. Он хорош именно в формате "эмулировать websocket" если же есть реальный веб сокет, лучше просто обычное состояние использовать и стм Если простая задача подойдёт и обычный useState/redux Если сложная redux-saga/redux-observable /rxjs

[@izzy7541]

Всё равно остались вопросы: 1. В большом приложении с большим количеством логики ключи запросов станут сложнее, а их количество вырастет. Как вы с этим боритесь? Запоминаете в уме где какие ключи использовать? 2. Типизация. В верхнем компоненте я получаю данные, рендерю все дочерние компоненты только в случае успеха. Но если я во вложенных компонентах захочу использовать эти же данные, то тайпскрипт также будет требовать обработки всех ситуаций (loading, error) хотя эти состояния в данном случае невозможны. Что в этом случае посоветуете? 3. Как быть если например хук useCreateTodo после своего выполнения должен инвалидировать разные ключи запросов? Тогда уже не получится передать в колбек onSetted/onSuccess инвалидацию так как она везде будет разная. Тем более в новой версии коллбеки внутри useQuery будут deprecated

[@paromovevg]

1. Вынесением в keyBuilders которые экспортируются из модуля и на них могут ссылаться другие модули при инвалидации 2. На самом деле 2 варианта. Забить и всегда использовать data?. Если useQuery используется только для отображения jsx (что я и советую) то в этом не будет проблем. Второй вариант можно воспользоваться suspence версией useQuery об этом можно найти в доке, в разделе сторонние решения 3. onSetteld и onSuccess удаляют из useQuery но не из useMutation иначе в этом небыло смысла. Опять же есть 2 варианта. 1. Ивалидировать всё и сразу. Инвалидация это не refetch, запрос не пойдёт если нет активных useQuery на странице. 2. Если вам действительно нужно 2 разных набора инвалидаций делать. То делаете 2 кастомных хука. Скорее всего в них будет какое то семантическое отличие которое можно отобразить в названии

[@paromovevg]

Нормально что остались вопросы, ведь это были только самые базовые правила

[@Graphouny77]

Есть ли для react-query аналог reselect как в redux? Для redux концепция селекторов очень нравилась, особенно если есть некая вложенность структур, или если нужно какие то данные с агрегировать.

[@paromovevg]

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

[@Graphouny77]

@@paromovevg допустим мы в ответе от апи получаем массив объектов, которые нам нужно сгруппировать к примеру на основе поля type, какие тут есть best practice для react-query, нужно в таком случае разные хуки ? В редаксе я бы создал 2 селектора, к примеру , selectLessons и selectTests из массива educationItems.

[@yuryk3397]

Для данных либа имба) А можно ли для авторизации использовать react query? Логин, рега, восстановление пароля - эти данные будто бы обособленно идут от основного домена приложения и из react query нужно лишь статус и результат запроса

[@paromovevg]

Для авторизации я её так использую. На логин регу и восстановление это обычные мутации. На успешный логин, запоминаю в СТМ/localStorage/Context состояние что человек авторизован. + на верхнем уровне декларативный вызван useMe который если сессия выходит возвращает 403 и состояние что человек авторизован переписывается в false И дальше везде в компонентах ниже, где нужен useMe просто его использую

[@Ramosok]

Решил воспользоваться твоим советом, поубирать refech и завязаться на смену ключа. Начал тестировать, и столкнулся с проблемой, да без рефеч работает, выглядит лучше, но у меня появился побочный эффект, стала перерисовываться страница после каждого запроса, с refech такого поведения нет, данные выводились в реалтайм. Я понимаю что без кода ты много не скажешь, но всё же, с чем может быть связано такое поведения?

[@paromovevg]

Скажу так, да будет перерисовка. Так как для react-query если другой ключ, то данные должны быть другими Возможно ты переделал логику перезапроса раз в некоторое время с помощью ключей. В этом случае как раз refetch (а лучше refetchInterval) лучше подходят

[@mrzipapupa]

Спасибо за видео! Очень боялся увидеть какие-то свои ошибки, но, благо до всего этого тоже дошёл) единственный вопрос - разве invaliateQueries(["todos"]) инвалидирует все дочерние кеши ? То есть ["todos", "list"], ["todos", "list", {sortBy: "date"}] и т.д.? Уже нет необходимости полный ключ кеша передавать для инвалидации? Или писать костыли, которые перебирают все включения "todos" и параллельно их инвалидируют) Спасибо)

[@paromovevg]

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

[@mrzipapupa]

@@paromovevg, спасибо! Пора, похоже, читать документацию снова)

[@maratzinatulin2749]

Столкнулся с такой проблемой, беру из useQuery - isLoading. Согласно его статусу я показываю лоадер или прачу. В первом запросе данных он отрабатывает. А при invalidateQueries или refetch isLoading не переходит в значение true, а обновляет страницу уже со значением false, когда данные получены. Это так специально задумано или необходимы дополные настройки?

[@vladislavpolovinkin6598]

Отрывки из доки _isLoading_ or _status === 'loading'_ - The query *has no data* and is currently fetching _isFetching_ - *In any state* , if the query is fetching at any time (including background refetching) _isFetching_ will be _true_ .

[@vladislavpolovinkin6598]

То есть если ты хочешь обрабатывать refetch, то тебе нужно значение isFetching, а не isLoading

[@maratzinatulin2749]

@@vladislavpolovinkin6598 Спасибо, попробуй с isFetching

[@mierce]

пишу на Java,видео не по моей споецифике,но очень интересно рассказываешь)

[@user-hruser]

Ключи надо хранить в спец объекте а то не найдёшь где что обновляет и инвалидирует