React + Mobx Гайд. Удобный state manager без бойлерплейта

[@webstack-frontend1697]

Мой курс, в котором мы разберем самые важные темы для собеседования: boosty.to/webstack-fe/purchase/1940940?ssource=DIRECT&share=subscription_link

[@Gurgen-k2n]

Отличное видео, зашел на проект с mobX, этого видео достаточно чтобы понять что к чему

[@webstack-frontend1697]

Спасибо за поддержку!

[@MgsMen]

Спасибо огромное дружище !! Устроился full stack. Нечего не шарю за фронт. Даже за JS. А у нас на проекте TypeScript и Mobx и твой пример прям помогает разобраться здесь и сейчас. Ни у кого не нашёл с примером Mobx + TS. А у тебя было, причём всё круто показал и объяснил. Жирнющий лайк тебе и спасибо !!

[@webstack-frontend1697]

Спасибо за поддержку!

[@rossmanov]

mobx прекрасная вещь! Скоро закончится время redux и redux toolkit.

[@cwlstorage]

Самое лучшее видео, которое встретил об MobX, всё понял с первого раза, хоть и не силён во фронте и на без использования ts и вообще пишу на классовых компонентах. Спасибо!)

[@webstack-frontend1697]

Спасибо за поддержку!

[@pika4u380]

Круто, давно хотел попробовать mobX, но руки не доходили. Действительно удобно. Удинственное, что я не согласен с уверждением, что можно безболезненно все компоненты оборачивать в memo. React так же расходует ресурсы на проверку небходимости перерисовывать компонент в memo и без последствий для производительности это не проходит

[@rasul7702]

Спасибо большое! Не думал что MobX настолько легкий, раньше даже не смотрел в его сторону

[@webstack-frontend1697]

Спасибо за поддержку!

[@JoSmith0]

Видео огонь!

[@webstack-frontend1697]

@@JoSmith0 спасибо за поддержку!

[@RuslanZolotoy]

Благодарю за такое подробное и понятное объяснение темы с MobX, пришёл на проект с этим state managerОМ)), твой контент выручает!

[@webstack-frontend1697]

Спасибо за поддержку!

[@dahulivsiozanjato]

Спасибо за такое лаконичное и понятное изложение! Суть ухватила

[@webstack-frontend1697]

Спасибо за поддержку!

[@banpoprichinechan]

Спасибо за ролик! Mobx кажется таким легким или я чего-то не знаю. Уже какое-то время работаю с ним, разобралась интуитивно, решила посмотреть тутор, чтобы всё уложить в голове. Прояснились некоторые моменты, особенно с контекстом)

[@lyamoore2194]

Просто, понятно и доступно. Спасибо!

[@webstack-frontend1697]

Спасибо за поддержку!

[@ЕгорСлепцов-х6б]

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

[@webstack-frontend1697]

Спасибо за поддержку! Учту)

[@sweety_emperor]

ну слушай... кайфовый гайд! прям огонь!

[@webstack-frontend1697]

Спасибо за поддержку!

[@ДанилАнтошкин-ш9т]

Хороший ролик по MobX, спасибо!

[@webstack-frontend1697]

Спасибо за поддержку!

[@Idealist2011]

А я видел, как сложные сторы-классы прокидывают как props drilling через все компоненты по иерархии. Это был трэш еще тот.

[@pashabezk]

Спасибо за отличное объяснение! MobX гораздо приятнее и интуитивнее Redux

[@webstack-frontend1697]

Спасибо за поддержку!

[@WorldCount]

А я как дурачок для каждого стора свой контекст создаю и оборачиваю приложения во все контексты через reducer. Спасибо

[@idontknowserjk8550]

Делаю установку на получение внимания от алгоритмов Ютуба. Спасибо!

[@webstack-frontend1697]

Спасибо за поддержку!)

[@igetout]

Пытаясь повторить код - поймал ошибку на 12:11. Когда через спред передаем пропсы, методы теряются, в компонент приходят undefined. Решается явным указанием свойств через пропсы, с потерей лаконичности((( Из того что нагуглил - спред-оператор копирует свойства, определенные непосредственно на объекте, методы могут не быть корректно привязаны или с копированы. То есть проблема возникала при копировании свойств, через spread. Видео супер, отличное, доступное и понятное объяснение, автору респект)

[@webstack-frontend1697]

Спасибо за отзыв! Честно говоря не знаю почему именно так могло получиться

[@igetout]

@@webstack-frontend1697 думаю, дело в конфиге tsc у меня, но я забил проверять. Оставил коммент, на случай, если у кого-то тоже проблема возникнет, чтобы время сэкономить)

[@multtanker6365]

спасибо, хороший ролик

[@webstack-frontend1697]

Спасибо за поддержку!

[@bogdannovac6556]

good content clear, and explicit

[@webstack-frontend1697]

Thx!

[@kostasancez2358]

Короче тема, надо попробовать

[@aimtimtimtim]

привет интересная подача а чем отличается то что ты достаешь поля класса через деструктуризацию от того что если создать инстанс класса через useState или нет разницы особо?

[@webstack-frontend1697]

Привет. Если я правильно понял вопрос, то через useState ты таким образом создашь локальный стор. А через экспортированный инстас класс доступ к нему будет из всех компонент

[@Andrew-pr6nb]

Спасибо!

[@valentineserebreanu398]

12:34 а если ты поставишь 2 компонента Wrapper а не один, то они же будут использовать один и тот же стор, и когда будешь один, будет меняться и другой) как это обходить? это же немного убивает компонентность. мы же не собираемся только один раз использовать компоненты

[@webstack-frontend1697]

Стор и не стоит использовать внутри глупой, переиспользуемой компоненты. Стор стоит использовать а неком "контейнере", который это все дело собирает вместе. Лично я создаю один стор на страницу и внутри этого стора собираю другие преисподьзуемые сторы

[@valentineserebreanu398]

@@webstack-frontend1697 так если я хочу два таких контейнера? то есть мобикс не переиспользуемый?) меня волнует масштабируемость, в данном подходе ее просто нет, и такую тяжелую либу как мобикс я бы 100% не использовал

[@imonutiy]

По-идее заворачивать в observer компоненты уже не нужно если есть Provider от контекста?

[@webstack-frontend1697]

@@imonutiy Насколько я знаю провайдера не достаточно

[@imonutiy]

@@webstack-frontend1697 Да, все правильно, перепроверил

[@ЕгорГоловин-в2й]

Не нужно оборачивать компонент в observer, если его родительский компонент уже обернут в Provider. Компонент Provider делает все состояние, определенное в MobX Store, доступным для всех его потомков. Это означает, что все дочерние компоненты могут получить доступ к состоянию и автоматически перерендериться при его изменении. Observer - это декоратор, который делает компонент наблюдателем за изменениями в состоянии. Если ваш родительский компонент уже обернут в Provider, то все дочерние компоненты автоматически являются наблюдателями, и observer становится избыточным.

[@webstack-frontend1697]

@@ЕгорГоловин-в2й mobx-cookbook.github.io/react-integration/context-api

[@ЕгорГоловин-в2й]

@@webstack-frontend1697 Перепроверил. Вы правы. В примере с Wrapper, как представлено в видео, действительно, нужно использовать observer, однако уже в дочерних компонентах его использование избыточно. Упустил контекст вопроса, спасибо что поправили. - оборенутый в observer - observer избыточен

[@makaroni1420]

Вопрос как обойтись без враппера, т.е. инициализировать стор в самом еомпоненте.

[@webstack-frontend1697]

Использовать хук useLocalObserver

[@valentynlugovyi4789]

Ок, cool

[@webstack-frontend1697]

Спасибо за поддержку!

[@ingane27]

А что вы думаете про effector?

[@webstack-frontend1697]

Честно говоря, я его ещё не успел потрогать

[@ingane27]

@@webstack-frontend1697ну в общем и целом effector не плох, но с миграцией на next 13 возникли проблемки которые пока что решить не удается

[@ЕвгенийЕ-б9б]

Привет! Спасибо за видео, отличная подача материала👍 Только вот остались вопросы по RootStore, когда все же его нужно использовать, а когда не стоит? Не сильно ли это скажется на оптимизации использование useContext?

[@webstack-frontend1697]

Если у вас разрослось приложение, и количество сторов растёт, как на дрожжах, стоит сразу прибегнуть к этой практике. На оптимизацию это сильно не влияет

[@VyacheslavMatyuk]

useContext для больших сторов использовать не рекомендуется. В этом хуке нет мемоизации, в результате будет куча лишних ререндеров. Этого можно избежать конечно дополнительными финтами, но ответ на ваш вопрос - опредленно повлияет на оптимизацию.

[@Bugagych]

Самый крутой ролик по mobx. А есть какой нибудь более обширный ролик, где написано приложение с использованием mobx? Хочется увидеть react-ts-mobx rest-api приложения, которое общается с разными микросервисами. Я на работе тоже использую mobx, но у меня есть только один стор, в котором всё и сразу. Только обращение к апи в соседнем файле. И не могу найти нормального видео, где показано как правильно дробить сторы, в каких случаях, как оптимизировать всё это.

[@webstack-frontend1697]

Привет. Спасибо за поддержку! Все в одном сторе это, точно, не хорошо. Пока такого видео нет, но в дальнейшем обязательно появится

[@Bugagych]

@@webstack-frontend1697 Очень жду)

[@skirrsolo4077]

@@webstack-frontend1697 очень хотим

[@олигТвистер]

На счет оборачивание всего в observer, ведь он под капотом библиотеки использует useMemo react. Tсли таким образом оборачивать статичные компоненты, не увеличит ли это рендер приложения?

[@webstack-frontend1697]

Не useMemo, а просто memo. Это аналог pureComponent. Это наоборот убирает лишние перерисовки при перерисовке родителя. Да и сам useMemo на рендеры никак не влияет

[@олигТвистер]

@@webstack-frontend1697 Спасибо

[@Вячеслав-у7ч7с]

А разве норм каждый раз создавать экземпляр RootStore при рендере App? Кажется, надо создать один экземпляр на все время жизни апки, независимо от ререндеров (а вдруг кто-то еще провайдером обернет снаружи и обновит провайдящееся значение?). Вижу, что в доке такое же, и собственно туда такой же вопрос.

[@webstack-frontend1697]

Не надо делать так, что бы App ререндерилась, даже без провайдеров это плохо, так как будет перерисовано все дерево. С созданием одного экземпляра я не экспериментировал. Если вдруг попробуешь, поделись здесь результатом)

[@SuperWhiteskull]

Я не понял, почему импортировать useStores() лучше, чем импортировать напрямую RootState? Сейчас перепишу проект себе, понажимаю, проверю.

[@SuperWhiteskull]

Понажимал. Всё работает. Мы просто из файла RootStore экспортируем инстанс класса new RootStore() и потом его везде используем. Во всех компонентах, где нам нужны будут посты, мы импортируем либо useStories() хук, либо наш RootState и из него достаём posts, но уже без оборачивания в провайдер. Если я что-то упускаю, напишите в комментариях, пожалуйста.

[@webstack-frontend1697]

@@SuperWhiteskull И для всех кому интересно, можно почитать тут mobx-cookbook.github.io/react-integration/context-api

[@ОлегСартаков-д6ц]

Могут возникнуть проблемы с цикличными зависимостями, некоторые проблемы при инициализации и тп. Рут лучше, хотя бы потому что можно добавить возможность доступа к соседним сторам из любого дочернего

[@alekseypotashov]

А кто является разработчиком Mobx? И с какого года он разрабатывается? Попытался нагуглить эту инфу и не нашел...

[@webstack-frontend1697]

Если вы про вырезку из прошлого комментария, то наверное я слишком заумно сказал, под инфой от разработчиков я имел ввиду инфу из документации. Это вырезка из документации mobx

[@iGotton]

+

[@r.chitector]

Начало было воодушевляющим. Но к концу весь mobx превратился в redux. Т.е. принципиально особого выигрыша нет, просто чуть чуть стройнее. Редакс точто так же при старте вроде писать не много, но потом объем кода нарастает сильно, как и тут. Это не волшебная пилюля. Думаю стоит смотреть в сторону атомарных стейтов. Там совсем другой подход. За примеры спасибо!

[@webstack-frontend1697]

На вкус и цвет, как говорится) А волшебной пилюли как по мне вообще не существует среди стейт менеджеров😅

[@zergzerg4844]

Не понравился MobX попробуй Zusland

[@grenadier4702]

И даже близко не редакс

[@sanek1985t]

Что такое атомарные стейты?

[@MirroXTV]

Zustand всё таки удобнее

[@webstack-frontend1697]

Ещё и зависимость легковестнее)

[@grenadier4702]

У Zustand , как по мне, жирный минус: селекторы

[@MrMegaFirestarter]

Да, редакс выглядит намного сложнее ! почему же редакс всё ещё так популярен ?

[@webstack-frontend1697]

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

[@ВсеволодЗахаров-я1ы]

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

[@MrMegaFirestarter]

@@ВсеволодЗахаров-я1ы До это я использовал только RTK вместе с AsyncThunk или RTK Query - мощно, но очень запутанно и не понятно до конца, что там происходит под капотом и как именно это там работает. А количество кода с редьюрерами, персистами, экшенами и проч. екстраредьюсерами очень смущает. Сейчас делаю проект только с mobX - меня впечатляет.

[@n1kson178]

Ситуация как с телеграм и ватсапп. Ватсапп все ещё популярнее, т.к. появился раньше

[@pick-pock]

Инерция в сообществе

[@ВиталийКопоров-и4в]

Rxjs на минималках

[@kotix_]

не могу смотреть видео с клацаньем клавиатуры в 2024 году

[@webstack-frontend1697]

Во всем виноват Razer, который до сих пор, в 2024, делает свои ужасные механические клавиатуры)

[@mephisto2226]

самое ужасное объяснение в рунете

[@nics51]

самое ахуенное, глаза шире открой и внимательно слушай

[@batpyiiikob7245]

Удобнее effector-а пока не видел..

[@webstack-frontend1697]

Ну пи про effector в связке с atomic router видео на канал уже подъехало)