В определённый момент react-query сменил своё направление и превратился в @tanstack/react-query. Это означает, что его основное ядро было выделено в отдельный пакет @tanstack/query-core. Благодаря этому стали доступны vue-query, solid-query и svelte-query.
Однако, к сожалению, не существует хороших решений по интеграции react-query с менеджерами состояний. Эта интеграция является весьма очевидной потребностью. В сложных проектах работа через хуки становится обременительной. Хуки связывают нас с жизненным циклом компонентов (например, useEffect выполняется после рендера, useState выполняется в пакетном режиме, а жизненный цикл данных привязан к циклу жизни приложения).
По этой причине сложную логику очень важно вынести за пределы компонентов. Тут возникает проблема, поскольку в основной поставке react-query имеется лишь встроенная в приложение система реактивности.
Многие в такой ситуации либо отказываются от react-query, либо интегрируют его на наименее удобный способ через useEffect.
Поскольку наш проект базировался на mobx, я решил рассмотреть возможности интеграции react-query с mobx. К своему удивлению я обнаружил идеальную интеграцию. Похоже, словно react-query и mobx были созданы друг для друга.
Посмотреть больше
Это пробный урок. Оформите подписку, чтобы получить доступ ко всем материалам курса. Премиум
Ограничение времени просмотра
Вы можете просматривать пробный урок только 10 минут. Получите полный доступ, чтобы смотреть без ограничений.
Меня зовут Евгений Паромов. Я Senior Front-end разработчик. 5 лет разрабатываю на React. Люблю много работать и за это время повидал около 20 проектов. 2 года использую FSD во всех проектах. Использовал FSD с React, Vue, React-query, Redux, Mobx, Next. Есть опыт миграции большого легаси на FSD (7 лет разработки нескольких команд). Есть опыт разработки проектов на FSD с нуля
Я на данный момент без подписки и не могу проверить это что вот это видео с его канала?
https://www.youtube.com/watch?v=03o9pgRVX1o
К показанному в видео есть две важные претензии:
- Автор делает одно ложное заявление, про отсутствие дублирования информации в его решении. И акцентирует на этом важном факторе как одном из ключевых источников проблем и ошибок. Предложенная реализация не избавляет нас от queryClient кеша, он всё так же присутствует, а данные в MobX сторе выступают дубликатом этих данных. Если бы queryClient кеш в такой реализации не создавался, то и не нужны были бы ключи для этого кеша.
- Встраивание логики сетевых запросов к серверу в модель, по-моему, является явным антипаттерном и вряд ли может быть рекомендуемым решением для применения в продакшене.
Anonymous
Спасибо, очень интересно
Команда внимательно читает ваши комментарии и оперативно на них реагирует. Вы можете спокойно оставлять запросы на обновления или задавать любые вопросы о курсе здесь.
Возможно, вы использовали другие библиотеки управления состоянием, такие как Redux или что-то еще, и вы наверняка поняли, что одной из самых больших проблем в ваших приложениях React является управление состоянием, и возникают следующие вопросы:
Этот курс содержит два примера реализации управления состоянием в React с использованием MobX и других решений. После этого курса я хочу, чтобы вы могли планировать состояние приложения в React. Для этого нам нужно рассмотреть более полные примеры. Таким образом, вместо того, чтобы просто узнать, когда использовать MobX, вы также узнаете, когда его не использовать и что использовать вместо него. Это важно, чтобы понять, какое место MobX занимает
Это самый обширный курс о MobX, который вы найдете в Интернете. После нескольких лет использования MobX я действительно стал увлечен им, поэтому решил создать этот курс, чтобы больше людей могли наслаждаться этой библиотекой управления состоянием.
https://www.youtube.com/watch?v=03o9pgRVX1o
К показанному в видео есть две важные претензии:
- Автор делает одно ложное заявление, про отсутствие дублирования информации в его решении. И акцентирует на этом важном факторе как одном из ключевых источников проблем и ошибок. Предложенная реализация не избавляет нас от queryClient кеша, он всё так же присутствует, а данные в MobX сторе выступают дубликатом этих данных. Если бы queryClient кеш в такой реализации не создавался, то и не нужны были бы ключи для этого кеша.
- Встраивание логики сетевых запросов к серверу в модель, по-моему, является явным антипаттерном и вряд ли может быть рекомендуемым решением для применения в продакшене.