Интеграция MobX и React Query — вопрос, который регулярно возникает в проектах со сложной бизнес-логикой. Ниже вы найдёте структурированное объяснение, почему связка работает идеально и как правильно её использовать.
Почему React Query изменил архитектуру и что это дало
С переходом на @tanstack/react-query библиотека получила новый фундамент — пакет @tanstack/query-core. Это позволило вынести логику работы с серверным состоянием в независимое ядро и использовать его не только в React, но и в других экосистемах: vue-query, solid-query, svelte-query.
Преимущества нового ядра
Единая логика запросов для разных фреймворков;
Отделение серверного состояния от UI-слоя;
Возможность гибкой интеграции с менеджерами состояний.
Где возникают сложности при использовании React Query
Несмотря на развитие экосистемы, у React Query есть недостаток — отсутствие нативной интеграции с популярными менеджерами состояния. В сложных проектах это приводит к проблемам:
Ограничения компонентного подхода
Хуки завязаны на жизненный цикл компонентов. Например, useEffect срабатывает только после рендера.
Состояние useState обновляется пакетно и подчиняется циклу рендера.
Жизненный цикл данных становится частью жизненного цикла UI, что усложняет логику.
Типичные способы решения (и их недостатки)
Отказ от React Query в пользу глобального состояния;
Перенос логики в useEffect, что усложняет кодовую базу;
Лишняя связка компонентов с данными.
Зачем выносить сложную логику из компонентов
В крупных проектах критически важно отделять бизнес-логику от UI. Это делает код чище, предсказуемее и более пригодным для тестирования. Однако стандартные возможности React Query ограничивают такие сценарии, потому что встроенная реактивность рассчитана преимущественно на использование внутри React-компонентов.
Идеальная совместимость mobx и react-query
Если ваш проект использует MobX, интеграция с React Query открывает удивительно элегантные решения.
Почему эта связка работает так хорошо
MobX предоставляет мощную реактивность, не зависящую от компонентов;
QueryCore можно обернуть в MobX-стор и контролировать запросы независимо от UI;
Наблюдаемые значения MobX автоматически триггерят перезапросы;
Получается «идеальный мост» между серверным и клиентским состоянием.
Результат интеграции
Создаётся ощущение, что MobX и React Query были разработаны друг для друга. Приложение становится проще, чище и гибче, а логика — полностью изолированной от UI.
Что будет дальше в курсе
В следующих разделах мы рассмотрим пошаговую интеграцию MobX и React Query, архитектурные паттерны и практические примеры из реальных проектов.
Это пробный урок. Оформите подписку, чтобы получить доступ ко всем материалам курса. Премиум
Ограничение времени просмотра
Вы можете просматривать пробный урок только 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 кеш в такой реализации не создавался, то и не нужны были бы ключи для этого кеша. - Встраивание логики сетевых запросов к серверу в модель, по-моему, является явным антипаттерном и вряд ли может быть рекомендуемым решением для применения в продакшене.
https://www.youtube.com/watch?v=03o9pgRVX1o
К показанному в видео есть две важные претензии:
- Автор делает одно ложное заявление, про отсутствие дублирования информации в его решении. И акцентирует на этом важном факторе как одном из ключевых источников проблем и ошибок. Предложенная реализация не избавляет нас от queryClient кеша, он всё так же присутствует, а данные в MobX сторе выступают дубликатом этих данных. Если бы queryClient кеш в такой реализации не создавался, то и не нужны были бы ключи для этого кеша.
- Встраивание логики сетевых запросов к серверу в модель, по-моему, является явным антипаттерном и вряд ли может быть рекомендуемым решением для применения в продакшене.