React + Mobx Гайд. Удобный state manager без бойлерплейта
HTML-код
- Опубликовано: 16 июн 2024
- Всем привет, на связи WebStack - Frontend. В этом выпуске мы познакомимся с популярным стейт менеджером для React приложения - Mobx.
Мой курс, в котором мы разберем самые важные темы для собеседования:
boosty.to/webstack-fe/purchas...
00:00 | Вступление
01:00 | Установка зависимостей
01:20 | Mobx стора на примере счетчка
09:24 | Переиспользования стора в нескольких компонентах
13:21 | Асинхронности в сторах
23:17 | Дебаг сторов
24:36 | Храним сторы в контексте
29:22 | Выводы
Поддержать канал:
boosty.to/webstack-fe
Репозиторий с проектами:
github.com/vosdux
Канал с советами для начинающих Frontend разработчиков:
t.me/vosduxFrontend
Чат где можно задать мне вопросы и пообщаться с другими начинающими фронтендерами:
t.me/+0FWmXELauK44NjRi
Наш Discord сервер:
/ discord
Мой курс, в котором мы разберем самые важные темы для собеседования:
boosty.to/webstack-fe/purchase/1940940?ssource=DIRECT&share=subscription_link
Спасибо за такое лаконичное и понятное изложение! Суть ухватила
Спасибо за поддержку!
Самое лучшее видео, которое встретил об MobX, всё понял с первого раза, хоть и не силён во фронте и на без использования ts и вообще пишу на классовых компонентах. Спасибо!)
Спасибо за поддержку!
Благодарю за такое подробное и понятное объяснение темы с MobX, пришёл на проект с этим state managerОМ)), твой контент выручает!
Спасибо за поддержку!
А я видел, как сложные сторы-классы прокидывают как props drilling через все компоненты по иерархии. Это был трэш еще тот.
Спасибо большое! Не думал что MobX настолько легкий, раньше даже не смотрел в его сторону
Спасибо за поддержку!
Классное видео, лаконично. Кстати для примера долгого выполнения запросов, можно использовать throttling
Спасибо за поддержку! Учту)
Хороший ролик по MobX, спасибо!
Спасибо за поддержку!
Отличное видео, зашел на проект с mobX, этого видео достаточно чтобы понять что к чему
Спасибо за поддержку!
Спасибо!
good content
clear, and explicit
Thx!
Короче тема, надо попробовать
Спасибо за ролик! Mobx кажется таким легким или я чего-то не знаю. Уже какое-то время работаю с ним, разобралась интуитивно, решила посмотреть тутор, чтобы всё уложить в голове. Прояснились некоторые моменты, особенно с контекстом)
спасибо, хороший ролик
Спасибо за поддержку!
ну слушай...
кайфовый гайд! прям огонь!
Спасибо за поддержку!
Пытаясь повторить код - поймал ошибку на 12:11. Когда через спред передаем пропсы, методы теряются, в компонент приходят undefined. Решается явным указанием свойств через пропсы, с потерей лаконичности((( Из того что нагуглил - спред-оператор копирует свойства, определенные непосредственно на объекте, методы могут не быть корректно привязаны или с копированы. То есть проблема возникала при копировании свойств, через spread. Видео супер, отличное, доступное и понятное объяснение, автору респект)
Спасибо за отзыв!
Честно говоря не знаю почему именно так могло получиться
@@webstack-frontend1697 думаю, дело в конфиге tsc у меня, но я забил проверять. Оставил коммент, на случай, если у кого-то тоже проблема возникнет, чтобы время сэкономить)
А я как дурачок для каждого стора свой контекст создаю и оборачиваю приложения во все контексты через reducer. Спасибо
Привет! Спасибо за видео, отличная подача материала👍
Только вот остались вопросы по RootStore, когда все же его нужно использовать, а когда не стоит? Не сильно ли это скажется на оптимизации использование useContext?
Если у вас разрослось приложение, и количество сторов растёт, как на дрожжах, стоит сразу прибегнуть к этой практике. На оптимизацию это сильно не влияет
useContext для больших сторов использовать не рекомендуется. В этом хуке нет мемоизации, в результате будет куча лишних ререндеров. Этого можно избежать конечно дополнительными финтами, но ответ на ваш вопрос - опредленно повлияет на оптимизацию.
Круто, давно хотел попробовать mobX, но руки не доходили. Действительно удобно. Удинственное, что я не согласен с уверждением, что можно безболезненно все компоненты оборачивать в memo. React так же расходует ресурсы на проверку небходимости перерисовывать компонент в memo и без последствий для производительности это не проходит
Делаю установку на получение внимания от алгоритмов Ютуба. Спасибо!
Спасибо за поддержку!)
привет интересная подача а чем отличается то что ты достаешь поля класса через деструктуризацию от того что если создать инстанс класса через useState или нет разницы особо?
Привет. Если я правильно понял вопрос, то через useState ты таким образом создашь локальный стор. А через экспортированный инстас класс доступ к нему будет из всех компонент
mobx прекрасная вещь! Скоро закончится время redux и redux toolkit.
Ок, cool
Спасибо за поддержку!
На счет оборачивание всего в observer, ведь он под капотом библиотеки использует useMemo react. Tсли таким образом оборачивать статичные компоненты, не увеличит ли это рендер приложения?
Не useMemo, а просто memo. Это аналог pureComponent. Это наоборот убирает лишние перерисовки при перерисовке родителя. Да и сам useMemo на рендеры никак не влияет
@@webstack-frontend1697 Спасибо
Спасибо за отличное объяснение! MobX гораздо приятнее и интуитивнее Redux
Спасибо за поддержку!
Самый крутой ролик по mobx. А есть какой нибудь более обширный ролик, где написано приложение с использованием mobx? Хочется увидеть react-ts-mobx rest-api приложения, которое общается с разными микросервисами.
Я на работе тоже использую mobx, но у меня есть только один стор, в котором всё и сразу. Только обращение к апи в соседнем файле. И не могу найти нормального видео, где показано как правильно дробить сторы, в каких случаях, как оптимизировать всё это.
Привет. Спасибо за поддержку! Все в одном сторе это, точно, не хорошо. Пока такого видео нет, но в дальнейшем обязательно появится
@@webstack-frontend1697 Очень жду)
@@webstack-frontend1697 очень хотим
+
12:34 а если ты поставишь 2 компонента Wrapper а не один, то они же будут использовать один и тот же стор, и когда будешь один, будет меняться и другой) как это обходить? это же немного убивает компонентность. мы же не собираемся только один раз использовать компоненты
Стор и не стоит использовать внутри глупой, переиспользуемой компоненты. Стор стоит использовать а неком "контейнере", который это все дело собирает вместе. Лично я создаю один стор на страницу и внутри этого стора собираю другие преисподьзуемые сторы
@@webstack-frontend1697 так если я хочу два таких контейнера? то есть мобикс не переиспользуемый?) меня волнует масштабируемость, в данном подходе ее просто нет, и такую тяжелую либу как мобикс я бы 100% не использовал
А что вы думаете про effector?
Честно говоря, я его ещё не успел потрогать
@@webstack-frontend1697ну в общем и целом effector не плох, но с миграцией на next 13 возникли проблемки которые пока что решить не удается
Вопрос как обойтись без враппера, т.е. инициализировать стор в самом еомпоненте.
Использовать хук useLocalObserver
А разве норм каждый раз создавать экземпляр RootStore при рендере App? Кажется, надо создать один экземпляр на все время жизни апки, независимо от ререндеров (а вдруг кто-то еще провайдером обернет снаружи и обновит провайдящееся значение?). Вижу, что в доке такое же, и собственно туда такой же вопрос.
Не надо делать так, что бы App ререндерилась, даже без провайдеров это плохо, так как будет перерисовано все дерево. С созданием одного экземпляра я не экспериментировал. Если вдруг попробуешь, поделись здесь результатом)
Я не понял, почему импортировать useStores() лучше, чем импортировать напрямую RootState?
Сейчас перепишу проект себе, понажимаю, проверю.
Понажимал. Всё работает. Мы просто из файла RootStore экспортируем инстанс класса new RootStore() и потом его везде используем. Во всех компонентах, где нам нужны будут посты, мы импортируем либо useStories() хук, либо наш RootState и из него достаём posts, но уже без оборачивания в провайдер. Если я что-то упускаю, напишите в комментариях, пожалуйста.
@@SuperWhiteskull И для всех кому интересно, можно почитать тут
mobx-cookbook.github.io/react-integration/context-api
А кто является разработчиком Mobx? И с какого года он разрабатывается? Попытался нагуглить эту инфу и не нашел...
Если вы про вырезку из прошлого комментария, то наверное я слишком заумно сказал, под инфой от разработчиков я имел ввиду инфу из документации. Это вырезка из документации mobx
Zustand всё таки удобнее
Ещё и зависимость легковестнее)
У Zustand , как по мне, жирный минус: селекторы
Начало было воодушевляющим. Но к концу весь mobx превратился в redux. Т.е. принципиально особого выигрыша нет, просто чуть чуть стройнее. Редакс точто так же при старте вроде писать не много, но потом объем кода нарастает сильно, как и тут. Это не волшебная пилюля. Думаю стоит смотреть в сторону атомарных стейтов. Там совсем другой подход. За примеры спасибо!
На вкус и цвет, как говорится)
А волшебной пилюли как по мне вообще не существует среди стейт менеджеров😅
Не понравился MobX попробуй Zusland
И даже близко не редакс
Что такое атомарные стейты?
Да, редакс выглядит намного сложнее ! почему же редакс всё ещё так популярен ?
Редакс появился намного раньше. А многие не любят изучать новое и переучиваться. Да и если проекту уже много лет, то переписывать его на новый стейт менеджер слишком трудозатратно
Просто редакс лучше, если говорить не о нативном редаксе, а о тулките и ртк. Вот его и используют.
@@user-fc8wy6mg1j До это я использовал только RTK вместе с AsyncThunk или RTK Query - мощно, но очень запутанно и не понятно до конца, что там происходит под капотом и как именно это там работает. А количество кода с редьюрерами, персистами, экшенами и проч. екстраредьюсерами очень смущает. Сейчас делаю проект только с mobX - меня впечатляет.
Ситуация как с телеграм и ватсапп. Ватсапп все ещё популярнее, т.к. появился раньше
Инерция в сообществе
Rxjs на минималках
не могу смотреть видео с клацаньем клавиатуры в 2024 году
Во всем виноват Razer, который до сих пор, в 2024, делает свои ужасные механические клавиатуры)
самое ужасное объяснение в рунете
Удобнее effector-а пока не видел..
Ну пи про effector в связке с atomic router видео на канал уже подъехало)