Comments 15
И всё же лучшая библиотека для управления состоянием - это MobX
И всё же лучшая библиотека для управления состоянием - это MobX
Истину глаголешь
Уже на двух проектах из за mobx были проблемы.
Основная проблема в том что у mobx богатый функционал и нужны строгие договоренности что из него используется. Когда происходит текучка людей, то начинаются эксперементы с его функционалом.
В двух командах остановились на том что для работы с данными с сервера используем react-query, для всего остального легковесные, простые инструменты, например zustand или обертки над реактовским провайдером.
Уже на двух проектах из за mobx были проблемы.
Какие именно проблемы? Проблемы именно из-за MobX или из-за чрезмерно умных разработчиков?)
Основная проблема в том что у mobx богатый функционал
Серьезно?) makeAutoObservabble, reaction, autorun, when и observer из mobx-react-lite, а всё остальное не нужно использовать.
В двух командах остановились на том что для работы с данными с сервера используем react-query
Зачем? Не догадались свою обертку для запросов к АПИ использовать внутри класса с состоянием компонента/или глобального состояния? Это же элементарно Ватсон.
Зачем засорять компоненты не нужным мусором и прибивать к реакту то, что не должно быть к нему прибито.
Вот например реакции. В некоторых модулях используют useEffect, в некоторых эффекты в react-query, в некоторых используют инструменты mobx. Начинаешь искать что где изменилось и это достаточно трудоемко.
Зачем? Не догадались свою обертку для запросов к АПИ использовать внутри класса с состоянием компонента/или глобального состояния? Это же элементарно Ватсон.
Это очевидное решение для тебя. Для другого разработчика будет очевидное решение другое. Когда идёт текучка людей у разных разработчиков разный бекграунд и уровень.
Зачем засорять компоненты не нужным мусором и прибивать к реакту то, что не должно быть к нему прибито.
Это тоже зависит от опыта и желания разработчиков.
Так в чем проблемы MobX'a то? Пока всё что я вижу из ваших комментариев это чисто проблемы низкой компетенции людей, а mobx/redux/и т.д. и т.п. тут не виноваты. Я так понимаю вы работаете там где вся команда состоит из таких, может конечно кто-то пытается прикидываться не джуном, но действия говорят за себя, тем более если у вас текучка, то понятное дело никто из серьезных специалистов работать на ваших условиях не будет
Условия разные и люди тоже. Я бы не судил так об уровне разработчика.
Был у меня проект, где mobx отлично себя показывал. Там вся логика была в классах, а реакт только для отображения. Его конечно тоже видоизменили потому, что люди, которые заложили ООП паттерны тоже ушли и следить за чистотой было некому.
Проблема была в том что порог входа был выше чем на типичных реактовских проектах.
Вообще mobx отличный инструмент, если строго ограничивать принципы работы с ним. Но как мы знаем, нам нужно быстро и дёшево. И используя таким образом mobx можно выстрелить себе в ногу.
Вы изначально написали
Уже на двух проектах из за mobx были проблемы.
В итоге, из-за mobx у вас не было проблем, у вас были проблемы из-за кривых рук разработчиков.
А значит, нет разницы Mobx, Zustand, Redux и т.п. они в любом случае будут писать гуано.
Просто используя MobX по сути большую времени ты просто пишешь нативный JS код и всё. А если просто тупо писать нативный код, читать свойства объекта/модифицировать свойства объекта и т.п. это проблема, поздравляю, вы джун) Не унывайте, рано или поздно наберетесь опыта и начнете делать все по красоте.
И используя таким образом mobx можно выстрелить себе в ногу.
И используя таким образом "подставь любое"(т.к. контекст говорит об использовании джунами) можно выстрелить себе в ногу.
Был у меня проект, где mobx отлично себя показывал. Там вся логика была в классах, а реакт только для отображения. Его конечно тоже видоизменили потому, что люди, которые заложили ООП паттерны тоже ушли и следить за чистотой было некому.
Ну т.е. ваш работодатель не платит ЗП по рынку и закономерно все серьезные специалисты уходят туда, где платят. И опять же, проблема в вашем конкретном работодателе и конкретном проекте, MobX опять же тут не причем.
Проблема была в том что порог входа был выше чем на типичных реактовских проектах.
Для кого? Для джунов? А с каких пор мы на них ориентируемся? В >90% они обычно отсутствуют на проектах ибо сильно тормозят его и срут в него, либо только там где максимально жадный работодатель который не хочет платить ЗП.
Ни за что не поверю что это завышает порог входа:
https://stackblitz.com/edit/vitejs-vite-dspjoj?file=src%2FApp.tsx&terminal=dev
1 раз объяснил что делает makeAutoObservable и observer (1-2 минуты времени) и любой джун способный вообще писать код на реакте, с точно таким же успехом справится если будет MobX.
Используем zustand, мне нравится.
Используем zustand, мне нравится.
Конечно, когда вы не знаете что вообще есть вокруг вам это УГ будет нравится. Попробуйте MobX, после него вы будете смотреть на zustand и т.п. как на гуано.
Предлагаю вам не гадать, что я знаю, а что нет. Никогда не угадаете.
Все инструменты ситуативные. В нашем случае zustand нам отлично подходит.
Предлагаю вам не гадать, что я знаю, а что нет. Никогда не угадаете.
Тут и так понятно что вы не знаете. Иначе вашего изначального коммента к этой статье не было бы.
Все инструменты ситуативные. В нашем случае zustand нам отлично подходит.
Когда речь идёт о front-end разработке в экосистеме реакта это не правильное утверждение. Т.к. тут безальтернативно React + MobX если вы не извращенец и мазохист. Ибо нет ни одного кейса и сценария где React + X(путь будет zustand) будет лучше, чем React + MobX.
Как работает Zustand