3 правила использования React Query
Вставка
- Опубліковано 16 лип 2023
- Смотреть на 1.5x -- записывался в 5 утра)
В этом видео мы на примере туду листа посмотрим какие есть классические проблемы неправильного использования React query
Подписывайтесь на мой telegram канал:
t.me/cleanfrontend
Исходники:
codesandbox.io/s/proud-leftpa... - Наука та технологія
Круто, ждём ещё рекомендаций, и про removeQueies, invalidatQueries, видосик)
Классное видео!
Крутое видео!! а когда будут еще видео про реакт квери?))) очень актуальная тема для более глубокого изучения)
Спасибо, с радостью я бы посмотрел пример как юзать реактквкри с фильтром и дебаунсом для обновления фильтра
Ощущение, будто пропустил какую-то вводную часть по react query))
Классное видео! Было бы интересно подробнее узнать про react query + websicket, если по сокету приходят не запросы на инвалидацию, а новые данные (например чат)
Моё скромное мнение что чат уже не для react-query задача. Он хорош именно в формате "эмулировать websocket" если же есть реальный веб сокет, лучше просто обычное состояние использовать и стм
Если простая задача подойдёт и обычный useState/redux
Если сложная redux-saga/redux-observable /rxjs
Всё равно остались вопросы:
1. В большом приложении с большим количеством логики ключи запросов станут сложнее, а их количество вырастет. Как вы с этим боритесь? Запоминаете в уме где какие ключи использовать?
2. Типизация. В верхнем компоненте я получаю данные, рендерю все дочерние компоненты только в случае успеха. Но если я во вложенных компонентах захочу использовать эти же данные, то тайпскрипт также будет требовать обработки всех ситуаций (loading, error) хотя эти состояния в данном случае невозможны. Что в этом случае посоветуете?
3. Как быть если например хук useCreateTodo после своего выполнения должен инвалидировать разные ключи запросов? Тогда уже не получится передать в колбек onSetted/onSuccess инвалидацию так как она везде будет разная. Тем более в новой версии коллбеки внутри useQuery будут deprecated
1. Вынесением в keyBuilders которые экспортируются из модуля и на них могут ссылаться другие модули при инвалидации
2. На самом деле 2 варианта. Забить и всегда использовать data?. Если useQuery используется только для отображения jsx (что я и советую) то в этом не будет проблем. Второй вариант можно воспользоваться suspence версией useQuery об этом можно найти в доке, в разделе сторонние решения
3. onSetteld и onSuccess удаляют из useQuery но не из useMutation иначе в этом небыло смысла. Опять же есть 2 варианта. 1. Ивалидировать всё и сразу. Инвалидация это не refetch, запрос не пойдёт если нет активных useQuery на странице. 2. Если вам действительно нужно 2 разных набора инвалидаций делать. То делаете 2 кастомных хука. Скорее всего в них будет какое то семантическое отличие которое можно отобразить в названии
Нормально что остались вопросы, ведь это были только самые базовые правила
Есть ли для react-query аналог reselect как в redux? Для redux концепция селекторов очень нравилась, особенно если есть некая вложенность структур, или если нужно какие то данные с агрегировать.
Сам хук useQuery предоставляет поле select в который как раз можно селектор передать, но это по большей части используется для оптимизации
@@paromovevg допустим мы в ответе от апи получаем массив объектов, которые нам нужно сгруппировать к примеру на основе поля type, какие тут есть best practice для react-query, нужно в таком случае разные хуки ? В редаксе я бы создал 2 селектора, к примеру , selectLessons и selectTests из массива educationItems.
Для данных либа имба)
А можно ли для авторизации использовать react query?
Логин, рега, восстановление пароля - эти данные будто бы обособленно идут от основного домена приложения и из react query нужно лишь статус и результат запроса
Для авторизации я её так использую.
На логин регу и восстановление это обычные мутации. На успешный логин, запоминаю в СТМ/localStorage/Context состояние что человек авторизован.
+ на верхнем уровне декларативный вызван useMe который если сессия выходит возвращает 403 и состояние что человек авторизован переписывается в false
И дальше везде в компонентах ниже, где нужен useMe просто его использую
Решил воспользоваться твоим советом, поубирать refech и завязаться на смену ключа. Начал тестировать, и столкнулся с проблемой, да без рефеч работает, выглядит лучше, но у меня появился побочный эффект, стала перерисовываться страница после каждого запроса, с refech такого поведения нет, данные выводились в реалтайм. Я понимаю что без кода ты много не скажешь, но всё же, с чем может быть связано такое поведения?
Скажу так, да будет перерисовка. Так как для react-query если другой ключ, то данные должны быть другими
Возможно ты переделал логику перезапроса раз в некоторое время с помощью ключей.
В этом случае как раз refetch (а лучше refetchInterval) лучше подходят
Спасибо за видео!
Очень боялся увидеть какие-то свои ошибки, но, благо до всего этого тоже дошёл)
единственный вопрос - разве invaliateQueries(["todos"]) инвалидирует все дочерние кеши ? То есть ["todos", "list"], ["todos", "list", {sortBy: "date"}] и т.д.? Уже нет необходимости полный ключ кеша передавать для инвалидации? Или писать костыли, которые перебирают все включения "todos" и параллельно их инвалидируют) Спасибо)
Да, это самая главная фича инвалидации и ключей, что можно ивалидировать без передачи ключа полностью
@@paromovevg, спасибо! Пора, похоже, читать документацию снова)
Столкнулся с такой проблемой, беру из useQuery - isLoading. Согласно его статусу я показываю лоадер или прачу. В первом запросе данных он отрабатывает. А при invalidateQueries или refetch isLoading не переходит в значение true, а обновляет страницу уже со значением false, когда данные получены. Это так специально задумано или необходимы дополные настройки?
Отрывки из доки
_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_ .
То есть если ты хочешь обрабатывать refetch, то тебе нужно значение isFetching, а не isLoading
@@vladislavpolovinkin6598 Спасибо, попробуй с isFetching
пишу на Java,видео не по моей споецифике,но очень интересно рассказываешь)
Ключи надо хранить в спец объекте а то не найдёшь где что обновляет и инвалидирует