Подходы к state management в React

[dominus_augustus]

Берите mobx и не мучайтесь

[globin_write]

Что забавно, MobX - единственный из списка, с кем реально пришлось помучаться)

[markelov69]

MobX - единственный из списка, с кем реально пришлось помучаться)

Как именно?

state.count++;
state.title = 'new title';

Где мучения? Все кто следил за state.count и state.title автоматически перендерились.

const myComp = observer(() => {
return <div>count: {state.count} / title: {state.title}</div>
})

Тут как бы все максимально просто и без лишнего кода.

[dominus_augustus]

Тоже интересно, в чем были мучения, вроде все просто

[DmitryKazakov8]

На Mobx можно писать так же, как в примере на Valtio, используя вместо proxy функцию observable. Единственное отличие в коде будет в том, что Mobx подключается к реактовым компонентам через враппинг в HOC observer, а Valtio - через useSnapshot. Плюсы Mobx подхода с враппингом в том, что можно использовать хоть 100 разных реактивных состояний в компоненте напрямую, без вызова для каждого useSnapshot, а сам враппинг можно сделать автоматически через бандлер, то есть компоненты в коде будут выглядеть чистыми.

Вариант с классовыми сторами просто более удобен в плане DX, поэтому часто выбирают его (меньше импортов и констант, меньше коллизии имен, не важен порядок объявления методов и геттеров). Но можно писать и объектами

[globin_write]

Хм, я, наоборот, меньше всего симпатизирую MobX из всего списка. Был не самый лучший опыт с большим проектом, где местами сложно понять, почему компонент перерендерился, так как зависимости отслеживаются автоматически.

В Redux/Zustand перерисовка явно связана с вызовом setState или dispatch, что с ростом масштаба кратно упрощает дебаг. Плюс DevTools у Redux (с логом действий и diffами состояния) гораздо мощнее, чем у MobX.

MobX очень гибок, у него этого не отнять. Но есть ощущение, что часто эта гибкость стреляет в ногу с ростом масштаба.

Безусловно, я далек от экспертности в контексте таких эджкейсов MobX. Если у вас есть опыт, как такое реашется, поделитесь, пожалуйста.

[DmitryKazakov8]

В Mobx тоже перерисовка связана явно, только вместо dispatch с полным пересозданием структуры здесь просто мутация store.param = value. Это дает намного более удобный DX - можно в IDE посмотреть все места, где читается/изменяется конкретное свойство и работают быстрые переходы.

А в Redux нужно сначала найти нужный initialState, потом найти десяток редюсеров, которые меняют в нем param, потом найти action name, по нему сделать полный поиск по проекту, чтобы найти все места где делается dispatch с этим названием экшена, не забыть пройтись по селекторам и connect HOC, чтобы узнать, где используются конкретный стор, а потом в каждом найденном компоненте искать где читается param. К сожалению, довольно много работал с Redux и пол-дня состояло как раз из этих действий, потому что никаких быстрых переходов или Find Usages у него не предусмотрено.

И с Redux в итоге не так-то просто найти, "почему компонент перерендерился", потому что нужно смотреть в Dev Tools и вручную искать какой именно из диспатчей данных повлиял на конкретный компонент, проходя все этапы, описанные выше. Но да, в нем есть диффы состояний, которые немного могут упростить процесс.

Дебажить кейс "почему компонент перерендерился" в целом непросто в любом подходе, и помогает тут скорее создание более атомарных компонентов, а не монстров с десятками состояний. Но с Mobx это как правило не нужно - компонент ререндерится при изменении читаемых свойств и если он перерендерился - значит нужно. Это не реактовый или редаксовый стейт, где все ререндерится даже если нечитаемые поля изменились, если тщательно не оптимизировать все через селекторы. Поэтому такой проблемы и не возникает

[clerik_r]

где местами сложно понять, почему компонент перерендерился, так как зависимости отслеживаются автоматически.

Ну так он перерндерился только если данные были изменены. Что за странная "сложность понять"? Ну читает у вас компонент 50 реактивных полей, одно изменилось - он перерендерился. С чего вообще вы вдруг решили объявить рендер компонента проблемой?)) Это нормально. Более того, я не могу представить задачу даже с помощью натягивания совы на глобус, где проблема была бы именно в MobX, а не в вашем компоненте. Т.е. "задача" понять при изменении какого именно поля произошел перерендер изначально не имеет никакого смысла практического. Ну а если так сильно хочется, то и у MobX есть dev tools. Но я dev tools мобикс вообще не пользуюсь уже как 8 лет работая с ним каждый день.