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