Комментарии 12
Неплохо! Хоть и можно было в данном случае информацию об отеле просто в "модалке" выводить и не рендерить каждый раз страницу результатов поиска при смене роута, а просто переключать свойство display, а для остального service-worker.
Но за статью спасибо, не знал о таких возможностях tanstack , надо будет доку получше почитать.
Статью не читал, потому что юзаю RQ на постоянстве.
*Интересный момент - при сильно связанной с бэком архитектуре, RQ (частично конечно), в достаточной степени заменяет RTK или MST. Иногда настолько, что я просто не подключаю глобальное состояние, а обновляю компонент с помощью кэша запроса. Имба короче - пользуйтесь.
Хорошая статья для начального знакомства с библиотекой, но упущено много возможностей, которые позволяют считать RQ именно стейт менеджером. Например - локальная мутация данных, инвалидация запросов, принудительный рефетч и далее.
Чтобы вытащить данные без пропс дриллинга нужно указать всё обязательные параметры useQuery. Иногда это может быть проблемой, обойти которую можно теме же пропсами или стейтом.
В пользу автора скажу, что на своём проекте мы полностью отказались от стейт менеджера и пока полёт нормальный 😀
Спасибо за статью, стейт менеджеры становятся не нужны. Но вот появился вопрос, а что делать когда пользователь сначала был не авторизован, а потом авторизовался? Ведь ему данные из кэша придут?
Можно добавить переменную в ключ и после авторизации будут перезапрошены данные с этой переменной в ключах.
Спасибо за комментарий. На самом деле у нас ровно так и работает, что помимо query параметров есть и другие переменные в ключе, которые важны для актуальности данных на странице и влияют на необходимость перезапросов.
Не стал показывать их на примерах, потому что в конкретно этом хуке такой зависимости нет :)
cтейт менеджеры становятся не нужны
Не путайте данные приложения (кеш), с ui-состоянием приложения. Есть толстые spa с достаточно богатой ui-логикой.
Например, есть многошаговая форма-визард. Валидационные правила поля на пятом шаге, зависят от комбинации значений полей на первом и третем шаге. Между шагами можно перемещаться без ограничений вперёд-назад в любое время, но если поле на втором шаге не заполнено - то перемещаться дальше нельзя. Между 4 и 5 шагами нужно показать или не показать модалку, которая в свою очередь тоже является формой, значения которой влияют на визуал пятого шага. И все эти правила "живые", т.е. периодически меняются, например, от фиче-флагов, локации юзера, и т.д.
Как такие кейсы разруливать без стейт-менеджера?)
Спасибо за развернутый комментарий :)
Вы не уточнили деталь про то, является ли эта форма многостраничной. Если нет, или мы создадим видимость многостраничности, то для таких случаев с формой можно было бы воспользоваться контекстом. Тогда мы смогли бы делиться состояниями между шагами формы, не пользуясь стейт менеджером.
Вы также упомянули необходимость валидации формы, поэтому еще более аккуратным методом (по моему мнению) было бы обернуть все в formik. Далее у нас была бы сразу валидация (с yup), и минимум кода, и нет необходимость затаскивать стейт менеджер.
Как вам такой вариант?
Формы - то был просто пример. Конечно же для роутинга - необходимо использовать соответствующую библиотеку, и для формочек также - formik, react-hook-form, whatever.
Контекст же вас всё-равно не спасёт - он "передёргивает" всех детей на каждый чих (сравните с нормальным стейт-менеджером, например с mobx).
Что касается примеров - пусть не формы, пусть будет какой-то онлайн-фотошоп, редактор аудио, или например webrtc-звонилка. Можно звонить нескольким людям, каждая линия показывает статус, длительность звонка в сек, кучу кнопочек (mute/unmute, hold, drop, increase/decrease volume, choose mic-input, choose audio-output). Между линиями можно прыгать, остальные должны удерживаться на холде. Линии можно мерджить в конференции. Во время текущего звонка - можно принимать дополнительные входящие и делать исходящие, а также шарится в менюшках\настройках других частей приложения, и всё должно подхватываться на лету.
Делать такое на контекстах..? рано или поздно он станет один, глобальным на всё приложение.
del
React Query: стейт-менеджер для любителей кэша