Все сильно зависит от специфики вашего проекта, но по своему опыту могу сказать, что ФП хранилища в проекте с бизнес-логикой - зачастую хуже, чем ООП варианты.
В своих проектах обычно использую стек из Mobx + tsyringe(DI). С недавних пор добавил в эту схему React-Query. Иногда бывает полезно использовать MST, если ваша бизнес логика требует каких-то сложных моделей данных с собственной логикой, а так же сложной связи между ними. В частности, MST дает немного больше возможностей для проектирования моделей данных, нежели обычные классы с Mobx.
Поясню за ответственности:
1. Mobx - отвечает именно за бизнес-логику frontend приложения. Не надо туда пихать геттеры данных с бэкенда, которые нужно просто визуализировать, для это есть React-Query. Поскольку Mobx базируется в первую очередь на классах, для работы с ним мы можем применять ООП и соответствующие паттерны, выстраивая интересно логику из хранилищ и сервисов прямо на frontend. Для лучшего понимания как это правильно варить, рекомендую глянуть на backend.
2. React-Query - у них на сайте прекрасно описано, зачем они нужны, и этот инструмент в любом случае призван дополнять типичные хранилища состояний, будь то хоть Mobx, хоть Redux, хоть еще что-либо, рекомендую почитать. Отличный инструмент для работы с состоянием приложение в случае тех данных, которые просто нужно взять с бэка и отобразить.
3. Tsyringe - для меня проверенный и неплохой инструмент для работы с DI на фронте. Это гораздо лучше, чем пробрасывать хранилища внутрь других хранилищ через конструкторы или через глобальные переменные. Аналогично с подключением в эту схему сервисов. Сразу скажу, что есть риск запутаться в конфигурациях сборщика, если используете CRA, ибо и Mobx, и Tsyringe используют в своей основе декораторы, а babel их переваривает с переменным успехом, но если разобраться, настроить можно)
Опять таки, адепты Redux и ФП могут сказать, что я просто не умею готовить Redux. Действительно, не умею. Несколько раз пытался трогать Redux, но он не нравился ни до того, как узнал про Mobx, ни после. Верю, что разрабатывать на нем можно. Но и ухо можно чесать левой рукой через затылок. Чтобы Redux был производительным и эффективным, нужно понимать как устроены данные и как работает его реактивность. Он может неплохо подойти для менеджмента состояния каких-то простых моделей данных, например, форм. Но зачем нам центральное хранилище для форм?
Mobx в этом плане сильно проще и при хорошей архитектуре проекта и самого приложения, джуниоры редко могут там что-то вытворить своеобразное, да и производительность там поломать куда сложнее. В общем, Mobx банально удобнее и проще, но при этом не только не ограничивает разработчиков в возможности создавать сложные и элегантные решения, а только помогает в этом.
Вот такие мысли, надеюсь поможет)
Простой
