Спасибо огромное дружище !! Устроился full stack. Нечего не шарю за фронт. Даже за JS. А у нас на проекте TypeScript и Mobx и твой пример прям помогает разобраться здесь и сейчас. Ни у кого не нашёл с примером Mobx + TS. А у тебя было, причём всё круто показал и объяснил. Жирнющий лайк тебе и спасибо !!
Самое лучшее видео, которое встретил об MobX, всё понял с первого раза, хоть и не силён во фронте и на без использования ts и вообще пишу на классовых компонентах. Спасибо!)
Круто, давно хотел попробовать mobX, но руки не доходили. Действительно удобно. Удинственное, что я не согласен с уверждением, что можно безболезненно все компоненты оборачивать в memo. React так же расходует ресурсы на проверку небходимости перерисовывать компонент в memo и без последствий для производительности это не проходит
Спасибо за ролик! Mobx кажется таким легким или я чего-то не знаю. Уже какое-то время работаю с ним, разобралась интуитивно, решила посмотреть тутор, чтобы всё уложить в голове. Прояснились некоторые моменты, особенно с контекстом)
Пытаясь повторить код - поймал ошибку на 12:11. Когда через спред передаем пропсы, методы теряются, в компонент приходят undefined. Решается явным указанием свойств через пропсы, с потерей лаконичности((( Из того что нагуглил - спред-оператор копирует свойства, определенные непосредственно на объекте, методы могут не быть корректно привязаны или с копированы. То есть проблема возникала при копировании свойств, через spread. Видео супер, отличное, доступное и понятное объяснение, автору респект)
@@webstack-frontend1697 думаю, дело в конфиге tsc у меня, но я забил проверять. Оставил коммент, на случай, если у кого-то тоже проблема возникнет, чтобы время сэкономить)
привет интересная подача а чем отличается то что ты достаешь поля класса через деструктуризацию от того что если создать инстанс класса через useState или нет разницы особо?
Привет. Если я правильно понял вопрос, то через useState ты таким образом создашь локальный стор. А через экспортированный инстас класс доступ к нему будет из всех компонент
12:34 а если ты поставишь 2 компонента Wrapper а не один, то они же будут использовать один и тот же стор, и когда будешь один, будет меняться и другой) как это обходить? это же немного убивает компонентность. мы же не собираемся только один раз использовать компоненты
Стор и не стоит использовать внутри глупой, переиспользуемой компоненты. Стор стоит использовать а неком "контейнере", который это все дело собирает вместе. Лично я создаю один стор на страницу и внутри этого стора собираю другие преисподьзуемые сторы
@@webstack-frontend1697 так если я хочу два таких контейнера? то есть мобикс не переиспользуемый?) меня волнует масштабируемость, в данном подходе ее просто нет, и такую тяжелую либу как мобикс я бы 100% не использовал
Привет! Спасибо за видео, отличная подача материала👍 Только вот остались вопросы по RootStore, когда все же его нужно использовать, а когда не стоит? Не сильно ли это скажется на оптимизации использование useContext?
Если у вас разрослось приложение, и количество сторов растёт, как на дрожжах, стоит сразу прибегнуть к этой практике. На оптимизацию это сильно не влияет
useContext для больших сторов использовать не рекомендуется. В этом хуке нет мемоизации, в результате будет куча лишних ререндеров. Этого можно избежать конечно дополнительными финтами, но ответ на ваш вопрос - опредленно повлияет на оптимизацию.
Не нужно оборачивать компонент в observer, если его родительский компонент уже обернут в Provider. Компонент Provider делает все состояние, определенное в MobX Store, доступным для всех его потомков. Это означает, что все дочерние компоненты могут получить доступ к состоянию и автоматически перерендериться при его изменении. Observer - это декоратор, который делает компонент наблюдателем за изменениями в состоянии. Если ваш родительский компонент уже обернут в Provider, то все дочерние компоненты автоматически являются наблюдателями, и observer становится избыточным.
@@webstack-frontend1697 Перепроверил. Вы правы. В примере с Wrapper, как представлено в видео, действительно, нужно использовать observer, однако уже в дочерних компонентах его использование избыточно. Упустил контекст вопроса, спасибо что поправили. - оборенутый в observer - observer избыточен
Самый крутой ролик по mobx. А есть какой нибудь более обширный ролик, где написано приложение с использованием mobx? Хочется увидеть react-ts-mobx rest-api приложения, которое общается с разными микросервисами. Я на работе тоже использую mobx, но у меня есть только один стор, в котором всё и сразу. Только обращение к апи в соседнем файле. И не могу найти нормального видео, где показано как правильно дробить сторы, в каких случаях, как оптимизировать всё это.
Начало было воодушевляющим. Но к концу весь mobx превратился в redux. Т.е. принципиально особого выигрыша нет, просто чуть чуть стройнее. Редакс точто так же при старте вроде писать не много, но потом объем кода нарастает сильно, как и тут. Это не волшебная пилюля. Думаю стоит смотреть в сторону атомарных стейтов. Там совсем другой подход. За примеры спасибо!
А разве норм каждый раз создавать экземпляр RootStore при рендере App? Кажется, надо создать один экземпляр на все время жизни апки, независимо от ререндеров (а вдруг кто-то еще провайдером обернет снаружи и обновит провайдящееся значение?). Вижу, что в доке такое же, и собственно туда такой же вопрос.
Не надо делать так, что бы App ререндерилась, даже без провайдеров это плохо, так как будет перерисовано все дерево. С созданием одного экземпляра я не экспериментировал. Если вдруг попробуешь, поделись здесь результатом)
Если вы про вырезку из прошлого комментария, то наверное я слишком заумно сказал, под инфой от разработчиков я имел ввиду инфу из документации. Это вырезка из документации mobx
Понажимал. Всё работает. Мы просто из файла RootStore экспортируем инстанс класса new RootStore() и потом его везде используем. Во всех компонентах, где нам нужны будут посты, мы импортируем либо useStories() хук, либо наш RootState и из него достаём posts, но уже без оборачивания в провайдер. Если я что-то упускаю, напишите в комментариях, пожалуйста.
Могут возникнуть проблемы с цикличными зависимостями, некоторые проблемы при инициализации и тп. Рут лучше, хотя бы потому что можно добавить возможность доступа к соседним сторам из любого дочернего
На счет оборачивание всего в observer, ведь он под капотом библиотеки использует useMemo react. Tсли таким образом оборачивать статичные компоненты, не увеличит ли это рендер приложения?
Не useMemo, а просто memo. Это аналог pureComponent. Это наоборот убирает лишние перерисовки при перерисовке родителя. Да и сам useMemo на рендеры никак не влияет
Редакс появился намного раньше. А многие не любят изучать новое и переучиваться. Да и если проекту уже много лет, то переписывать его на новый стейт менеджер слишком трудозатратно
@@ВсеволодЗахаров-я1ы До это я использовал только RTK вместе с AsyncThunk или RTK Query - мощно, но очень запутанно и не понятно до конца, что там происходит под капотом и как именно это там работает. А количество кода с редьюрерами, персистами, экшенами и проч. екстраредьюсерами очень смущает. Сейчас делаю проект только с mobX - меня впечатляет.
Мой курс, в котором мы разберем самые важные темы для собеседования:
boosty.to/webstack-fe/purchase/1940940?ssource=DIRECT&share=subscription_link
Спасибо огромное дружище !! Устроился full stack. Нечего не шарю за фронт. Даже за JS. А у нас на проекте TypeScript и Mobx и твой пример прям помогает разобраться здесь и сейчас. Ни у кого не нашёл с примером Mobx + TS. А у тебя было, причём всё круто показал и объяснил. Жирнющий лайк тебе и спасибо !!
Спасибо за поддержку!
Самое лучшее видео, которое встретил об MobX, всё понял с первого раза, хоть и не силён во фронте и на без использования ts и вообще пишу на классовых компонентах. Спасибо!)
Спасибо за поддержку!
Спасибо большое! Не думал что MobX настолько легкий, раньше даже не смотрел в его сторону
Спасибо за поддержку!
Круто, давно хотел попробовать mobX, но руки не доходили. Действительно удобно. Удинственное, что я не согласен с уверждением, что можно безболезненно все компоненты оборачивать в memo. React так же расходует ресурсы на проверку небходимости перерисовывать компонент в memo и без последствий для производительности это не проходит
Благодарю за такое подробное и понятное объяснение темы с MobX, пришёл на проект с этим state managerОМ)), твой контент выручает!
Спасибо за поддержку!
Просто, понятно и доступно. Спасибо!
Спасибо за поддержку!
Спасибо за такое лаконичное и понятное изложение! Суть ухватила
Спасибо за поддержку!
Спасибо за ролик! Mobx кажется таким легким или я чего-то не знаю. Уже какое-то время работаю с ним, разобралась интуитивно, решила посмотреть тутор, чтобы всё уложить в голове. Прояснились некоторые моменты, особенно с контекстом)
А я как дурачок для каждого стора свой контекст создаю и оборачиваю приложения во все контексты через reducer. Спасибо
ну слушай...
кайфовый гайд! прям огонь!
Спасибо за поддержку!
Делаю установку на получение внимания от алгоритмов Ютуба. Спасибо!
Спасибо за поддержку!)
А я видел, как сложные сторы-классы прокидывают как props drilling через все компоненты по иерархии. Это был трэш еще тот.
Спасибо за отличное объяснение! MobX гораздо приятнее и интуитивнее Redux
Спасибо за поддержку!
mobx прекрасная вещь! Скоро закончится время redux и redux toolkit.
Короче тема, надо попробовать
good content
clear, and explicit
Thx!
спасибо, хороший ролик
Спасибо за поддержку!
Пытаясь повторить код - поймал ошибку на 12:11. Когда через спред передаем пропсы, методы теряются, в компонент приходят undefined. Решается явным указанием свойств через пропсы, с потерей лаконичности((( Из того что нагуглил - спред-оператор копирует свойства, определенные непосредственно на объекте, методы могут не быть корректно привязаны или с копированы. То есть проблема возникала при копировании свойств, через spread. Видео супер, отличное, доступное и понятное объяснение, автору респект)
Спасибо за отзыв!
Честно говоря не знаю почему именно так могло получиться
@@webstack-frontend1697 думаю, дело в конфиге tsc у меня, но я забил проверять. Оставил коммент, на случай, если у кого-то тоже проблема возникнет, чтобы время сэкономить)
Спасибо!
привет интересная подача а чем отличается то что ты достаешь поля класса через деструктуризацию от того что если создать инстанс класса через useState или нет разницы особо?
Привет. Если я правильно понял вопрос, то через useState ты таким образом создашь локальный стор. А через экспортированный инстас класс доступ к нему будет из всех компонент
Вопрос как обойтись без враппера, т.е. инициализировать стор в самом еомпоненте.
Использовать хук useLocalObserver
12:34 а если ты поставишь 2 компонента Wrapper а не один, то они же будут использовать один и тот же стор, и когда будешь один, будет меняться и другой) как это обходить? это же немного убивает компонентность. мы же не собираемся только один раз использовать компоненты
Стор и не стоит использовать внутри глупой, переиспользуемой компоненты. Стор стоит использовать а неком "контейнере", который это все дело собирает вместе. Лично я создаю один стор на страницу и внутри этого стора собираю другие преисподьзуемые сторы
@@webstack-frontend1697 так если я хочу два таких контейнера? то есть мобикс не переиспользуемый?) меня волнует масштабируемость, в данном подходе ее просто нет, и такую тяжелую либу как мобикс я бы 100% не использовал
Привет! Спасибо за видео, отличная подача материала👍
Только вот остались вопросы по RootStore, когда все же его нужно использовать, а когда не стоит? Не сильно ли это скажется на оптимизации использование useContext?
Если у вас разрослось приложение, и количество сторов растёт, как на дрожжах, стоит сразу прибегнуть к этой практике. На оптимизацию это сильно не влияет
useContext для больших сторов использовать не рекомендуется. В этом хуке нет мемоизации, в результате будет куча лишних ререндеров. Этого можно избежать конечно дополнительными финтами, но ответ на ваш вопрос - опредленно повлияет на оптимизацию.
По-идее заворачивать в observer компоненты уже не нужно если есть Provider от контекста?
@@imonutiy Насколько я знаю провайдера не достаточно
@@webstack-frontend1697 Да, все правильно, перепроверил
Не нужно оборачивать компонент в observer, если его родительский компонент уже обернут в Provider.
Компонент Provider делает все состояние, определенное в MobX Store, доступным для всех его потомков. Это означает, что все дочерние компоненты могут получить доступ к состоянию и автоматически перерендериться при его изменении.
Observer - это декоратор, который делает компонент наблюдателем за изменениями в состоянии. Если ваш родительский компонент уже обернут в Provider, то все дочерние компоненты автоматически являются наблюдателями, и observer становится избыточным.
@@ЕгорГоловин-в2й mobx-cookbook.github.io/react-integration/context-api
@@webstack-frontend1697 Перепроверил. Вы правы. В примере с Wrapper, как представлено в видео, действительно, нужно использовать observer, однако уже в дочерних компонентах его использование избыточно. Упустил контекст вопроса, спасибо что поправили.
- оборенутый в observer
- observer избыточен
Ок, cool
Спасибо за поддержку!
Самый крутой ролик по mobx. А есть какой нибудь более обширный ролик, где написано приложение с использованием mobx? Хочется увидеть react-ts-mobx rest-api приложения, которое общается с разными микросервисами.
Я на работе тоже использую mobx, но у меня есть только один стор, в котором всё и сразу. Только обращение к апи в соседнем файле. И не могу найти нормального видео, где показано как правильно дробить сторы, в каких случаях, как оптимизировать всё это.
Привет. Спасибо за поддержку! Все в одном сторе это, точно, не хорошо. Пока такого видео нет, но в дальнейшем обязательно появится
@@webstack-frontend1697 Очень жду)
@@webstack-frontend1697 очень хотим
Начало было воодушевляющим. Но к концу весь mobx превратился в redux. Т.е. принципиально особого выигрыша нет, просто чуть чуть стройнее. Редакс точто так же при старте вроде писать не много, но потом объем кода нарастает сильно, как и тут. Это не волшебная пилюля. Думаю стоит смотреть в сторону атомарных стейтов. Там совсем другой подход. За примеры спасибо!
На вкус и цвет, как говорится)
А волшебной пилюли как по мне вообще не существует среди стейт менеджеров😅
Не понравился MobX попробуй Zusland
И даже близко не редакс
Что такое атомарные стейты?
+
А разве норм каждый раз создавать экземпляр RootStore при рендере App? Кажется, надо создать один экземпляр на все время жизни апки, независимо от ререндеров (а вдруг кто-то еще провайдером обернет снаружи и обновит провайдящееся значение?). Вижу, что в доке такое же, и собственно туда такой же вопрос.
Не надо делать так, что бы App ререндерилась, даже без провайдеров это плохо, так как будет перерисовано все дерево. С созданием одного экземпляра я не экспериментировал. Если вдруг попробуешь, поделись здесь результатом)
Zustand всё таки удобнее
Ещё и зависимость легковестнее)
У Zustand , как по мне, жирный минус: селекторы
А кто является разработчиком Mobx? И с какого года он разрабатывается? Попытался нагуглить эту инфу и не нашел...
Если вы про вырезку из прошлого комментария, то наверное я слишком заумно сказал, под инфой от разработчиков я имел ввиду инфу из документации. Это вырезка из документации mobx
А что вы думаете про effector?
Честно говоря, я его ещё не успел потрогать
@@webstack-frontend1697ну в общем и целом effector не плох, но с миграцией на next 13 возникли проблемки которые пока что решить не удается
Я не понял, почему импортировать useStores() лучше, чем импортировать напрямую RootState?
Сейчас перепишу проект себе, понажимаю, проверю.
Понажимал. Всё работает. Мы просто из файла RootStore экспортируем инстанс класса new RootStore() и потом его везде используем. Во всех компонентах, где нам нужны будут посты, мы импортируем либо useStories() хук, либо наш RootState и из него достаём posts, но уже без оборачивания в провайдер. Если я что-то упускаю, напишите в комментариях, пожалуйста.
@@SuperWhiteskull И для всех кому интересно, можно почитать тут
mobx-cookbook.github.io/react-integration/context-api
Могут возникнуть проблемы с цикличными зависимостями, некоторые проблемы при инициализации и тп. Рут лучше, хотя бы потому что можно добавить возможность доступа к соседним сторам из любого дочернего
На счет оборачивание всего в observer, ведь он под капотом библиотеки использует useMemo react. Tсли таким образом оборачивать статичные компоненты, не увеличит ли это рендер приложения?
Не useMemo, а просто memo. Это аналог pureComponent. Это наоборот убирает лишние перерисовки при перерисовке родителя. Да и сам useMemo на рендеры никак не влияет
@@webstack-frontend1697 Спасибо
Да, редакс выглядит намного сложнее ! почему же редакс всё ещё так популярен ?
Редакс появился намного раньше. А многие не любят изучать новое и переучиваться. Да и если проекту уже много лет, то переписывать его на новый стейт менеджер слишком трудозатратно
Просто редакс лучше, если говорить не о нативном редаксе, а о тулките и ртк. Вот его и используют.
@@ВсеволодЗахаров-я1ы До это я использовал только RTK вместе с AsyncThunk или RTK Query - мощно, но очень запутанно и не понятно до конца, что там происходит под капотом и как именно это там работает. А количество кода с редьюрерами, персистами, экшенами и проч. екстраредьюсерами очень смущает. Сейчас делаю проект только с mobX - меня впечатляет.
Ситуация как с телеграм и ватсапп. Ватсапп все ещё популярнее, т.к. появился раньше
Инерция в сообществе
не могу смотреть видео с клацаньем клавиатуры в 2024 году
Во всем виноват Razer, который до сих пор, в 2024, делает свои ужасные механические клавиатуры)
Rxjs на минималках
самое ужасное объяснение в рунете
Удобнее effector-а пока не видел..
Ну пи про effector в связке с atomic router видео на канал уже подъехало)
Отличное видео, зашел на проект с mobX, этого видео достаточно чтобы понять что к чему
Спасибо за поддержку!
Классное видео, лаконично. Кстати для примера долгого выполнения запросов, можно использовать throttling
Спасибо за поддержку! Учту)
Хороший ролик по MobX, спасибо!
Спасибо за поддержку!