Мне кажется, это что-то типо локального вида спорта у js комьюнити - плодить либы по поводу и без.
Если серьезно, то по сути реальная разница есть между либами, которые мутируют объекты (mobx, valtio, ...) и теми, кто идёт по пути реакта и объекты не мутирует.
А в рамках одной группы разница не так велика. Я, наверное, соберу ещё хейта за такие мысли, но разница буквально в предпочтительных паттернах и синтаксисе.
Если прям интересно, очень рекомендую книгу "Micro state Management react hooks". Читается за день, даёт ответы на большинство вопросов связанных с см в контексте react приложений.
Думаю, мое мнение сложилось исходя из сложностей, с которыми пришлось столкнуться при знакомстве с технологией (это был легаси, сменивший много команд, у каждой из которых было свое виденье того, как стейт должен выглядеть).
Все стейт менеджеры хороши, и холивар тут как бы нет причин начинать. речь в статье именно о эджкейсах, т.е. исключениях, а не правилах.
Сложно сравнить хорошие продукты, которыми являются и mobX и его конкуренты, поэтому я и говорю о крайних случаях, где одни чуть лучче других, по моему опыту.
Это на самом деле очень хороший комментарий, спасибо за информацию!
Могу только сказать, что я не хотел выставить mobX в плохом свете или вроде того. Мой опыт с ним был в жестком легаси, где команды сменяли команды и легко там быть определенно не может.
Я о том, что более структурированный и декларативный redux, по моему опыту, в случае подобного легаси был бы предпочтительнее, потому что "распутать" состояние в его случае как будто проще.
Ваш довод про "если он перерендерился - значит нужно" прекрасно работает, если разработчики, как изначально пишущие менеджмент состояния, так и после поддерживающие проект, знали, что они делают. Если это условие не соблюдается, как и было в моем случае, как раз и происходит описываемая проблема. У других стейт менеджеров она бы тоже имела место, но, по моему мнению, не в этом масштабе.
Приведенный вами пример действительно не вызовет мучений, вне зависимости от выбранной технологии стейт менеджмента. Я столкнулся с проблемой на проекте с большими объектами в сторе, к тому же, довольно плохо реализованном.
Фраза про "мучения" не должна быть воспринята буквально. То есть, все стейт менеджеры из статьи это решения, доказавшие свою эффективность на огромном числе проектов, redux и mobx особенно.
Тут речь больше про "защиту от дурака". Тот же zustand, который, я, к слову, очень люблю, такой тоже не обладает, по моему опыту. Так что его использование как основного стейт менеджера в больших аппках может быть рисковано.
При использовании реактивного mobx в декларативном реакте существует, на мой взгляд, больше возможностей создать себе проблемы.
Опытная команда, уверен, избежит этого, но таких, как мы видим, меньшинство.
Хм, я, наоборот, меньше всего симпатизирую MobX из всего списка. Был не самый лучший опыт с большим проектом, где местами сложно понять, почему компонент перерендерился, так как зависимости отслеживаются автоматически.
В Redux/Zustand перерисовка явно связана с вызовом setState или dispatch, что с ростом масштаба кратно упрощает дебаг. Плюс DevTools у Redux (с логом действий и diffами состояния) гораздо мощнее, чем у MobX.
MobX очень гибок, у него этого не отнять. Но есть ощущение, что часто эта гибкость стреляет в ногу с ростом масштаба.
Безусловно, я далек от экспертности в контексте таких эджкейсов MobX. Если у вас есть опыт, как такое реашется, поделитесь, пожалуйста.
А чем хуже? По вашему мнению. Я с ними не работал, экспертизы тут не имею
Мне кажется, это что-то типо локального вида спорта у js комьюнити - плодить либы по поводу и без.
Если серьезно, то по сути реальная разница есть между либами, которые мутируют объекты (mobx, valtio, ...) и теми, кто идёт по пути реакта и объекты не мутирует.
А в рамках одной группы разница не так велика. Я, наверное, соберу ещё хейта за такие мысли, но разница буквально в предпочтительных паттернах и синтаксисе.
Если прям интересно, очень рекомендую книгу "Micro state Management react hooks". Читается за день, даёт ответы на большинство вопросов связанных с см в контексте react приложений.
Делаю, что могу)))
Знал, на что я шел
А тут все просто, не использовал их еще)
Думаю, мое мнение сложилось исходя из сложностей, с которыми пришлось столкнуться при знакомстве с технологией (это был легаси, сменивший много команд, у каждой из которых было свое виденье того, как стейт должен выглядеть).
Все стейт менеджеры хороши, и холивар тут как бы нет причин начинать. речь в статье именно о эджкейсах, т.е. исключениях, а не правилах.
Сложно сравнить хорошие продукты, которыми являются и mobX и его конкуренты, поэтому я и говорю о крайних случаях, где одни чуть лучче других, по моему опыту.
Это на самом деле очень хороший комментарий, спасибо за информацию!
Могу только сказать, что я не хотел выставить mobX в плохом свете или вроде того. Мой опыт с ним был в жестком легаси, где команды сменяли команды и легко там быть определенно не может.
Я о том, что более структурированный и декларативный redux, по моему опыту, в случае подобного легаси был бы предпочтительнее, потому что "распутать" состояние в его случае как будто проще.
Ваш довод про "если он перерендерился - значит нужно" прекрасно работает, если разработчики, как изначально пишущие менеджмент состояния, так и после поддерживающие проект, знали, что они делают. Если это условие не соблюдается, как и было в моем случае, как раз и происходит описываемая проблема. У других стейт менеджеров она бы тоже имела место, но, по моему мнению, не в этом масштабе.
Ответил выше)
Интересно ваше мнение
Приведенный вами пример действительно не вызовет мучений, вне зависимости от выбранной технологии стейт менеджмента. Я столкнулся с проблемой на проекте с большими объектами в сторе, к тому же, довольно плохо реализованном.
Фраза про "мучения" не должна быть воспринята буквально. То есть, все стейт менеджеры из статьи это решения, доказавшие свою эффективность на огромном числе проектов, redux и mobx особенно.
Тут речь больше про "защиту от дурака". Тот же zustand, который, я, к слову, очень люблю, такой тоже не обладает, по моему опыту. Так что его использование как основного стейт менеджера в больших аппках может быть рисковано.
При использовании реактивного mobx в декларативном реакте существует, на мой взгляд, больше возможностей создать себе проблемы.
Опытная команда, уверен, избежит этого, но таких, как мы видим, меньшинство.
Что забавно, MobX - единственный из списка, с кем реально пришлось помучаться)
Хм, я, наоборот, меньше всего симпатизирую MobX из всего списка. Был не самый лучший опыт с большим проектом, где местами сложно понять, почему компонент перерендерился, так как зависимости отслеживаются автоматически.
В Redux/Zustand перерисовка явно связана с вызовом
setStateилиdispatch, что с ростом масштаба кратно упрощает дебаг. Плюс DevTools у Redux (с логом действий и diffами состояния) гораздо мощнее, чем у MobX.MobX очень гибок, у него этого не отнять. Но есть ощущение, что часто эта гибкость стреляет в ногу с ростом масштаба.
Безусловно, я далек от экспертности в контексте таких эджкейсов MobX. Если у вас есть опыт, как такое реашется, поделитесь, пожалуйста.