стор должен хранить в себе данные и иметь возможность их изменять, он не должен вызывать side-эффекты при вызове какого-нибудь действия. Стор - это просто состояние. Асинхронный код должен вызываться вне стора, совершенно отдельно. Например у тебя есть форма, при её сохранении ты хочешь отправить запрос на сервер, а потом записать что-то (например вернувшийся id, хз) в стор, то вместо того, чтобы делать запрос в действии стора, следует сделать запрос просто в обычной ф-ии, а по его завершении вызвать, например setObjectId() из стора.
@@MaksTrueman масштабируемость, например. Это банальное разграничение зон ответственности и если его не будет - будет страдать масштабируемость, будет сложнее вводить новых сотрудников в курс дела и следить за тем, чтобы они не косячили
с последних проектов, с которыми сталкивался, складывается впечатление, что редакс выбирают чисто из-за работы с привычным стеком, который себя вроде как зарекомендовал в прошлом но после того, как на одном из проектов заменил ядерную комбинацию redux-toolkit + saga (засетапленную не мной), на zustand + react-query, понял, что скорость выполнения задач возросла в разы и особого смысла в редаксе уже как бы и нету имхо да, можно спорить про архитектурные моменты, разделение кода и ответственности и бла-бла-бла, но по факту проект, который сейчас разросся до огромного приложения, отлично себя чувствует на рельсах зустанда вот кое-что на вентилятор и, возможно, "на обсудить" - некоторые "архитектурные" принципы возникли из-за редакса и теперь просто не налезают на современные тулзы вроде зустанда, т.к. просто не нужны :)
Сегодня буквально смотрел проектик, помочь нужно, там тоже стэк redux-toolkit + saga. ЗАчем вообще saga, если в toolkit уже встроен RTK Query?? Т.е. выбор zustand + react-query просто отсеял redux :Ъ А вот концепции saga не понял, но с ней и не работал никогда, может и есть чего ультраимбового
@@bebeto123g ультрабойлерплейт наподобие старого редакса =)) забавно что поверх саг даже либу написали для минимизации однотипных действий (redux-saga-routines)
Redux сейчас идёт вместе с rtk-query . Zustand, наверное, придется использовать с react-query. Было бы интересно сравнить удобство пользования и размер
Главное их не смешивать. Видел дичь, когда люди делают запросы через react-query и сохраняют сетевой кеш внутри zustand :) Т.е. полное непонимание смысла react-query.
По своему опыту скажу, что удобнее rtk-query, тем более, что в комплекте идёт state и в этом есть плюсы при взаимодействии. По размерам, написал в недавнем посте)
@@АлександрВолков-о8ю мне кажется react query намного проще. вот допустим на нем вообще легко сделать infinite query, а в rtk query чет нужно самому придумывать и возиться с этим..
@@АлександрВолков-о8ю я ни разу не работал с rtk-query, на проектах используем @tanstack/query + zustand/mobx, но посмотрев на примеры кода в документации, я не могу представить ситуацию, в которой мы хоть на одном нормальном продакт решении попробуем это вместо @tanstack/query. Конечно ради саморазвития я попробую что-нибудь сварганить с помощью него, но выглядит это как просто ненужное нагромождение всего и вся. В китченсинке вообще получается что rtk - это ещё и замена стандартного fetch/axios. А что, если меня fetch устраивает? А что, если у меня вообще запрос ни к апи делается, а к веб воркеру например (с помощью щепотки магии)? Не знаю, может я просто слишком сильно отдалился от концепции глобальных состояний (в частности благодаря @tanstack/query & react-hook-form), но всё это выглядит абсолютно необязательным, да ещё и сильно повышает порог входа в проект. Конечно, разобраться с этим можно за пару часов, при желании, но я просто реально не понимаю: зачем? В чём преимущество такого подхода? Масштабируемость? Нет, огромный монорепозиторий с кучей модулей спокойно работает и без этого и, скорей всего, с меньшим coupling'ом. Необходимость? Непонятно в чём заключается. Удобство? Тоже не понятно где.
О, это Вы еще значит не знаете про Valtio :-) вот эта мне реально понравилась. Особенно то что оно работает как для React'а, так и для Vanilla. Т.е. я могу снаружи изменить стейт и компонент перерисуется, плюс я гонял его на SSR и на клиенте, прекрасно работает.
использовать можно в простых случаях, когда только прочитать записать в модуле, просто как некий более глобальный стейт для модуля и компонентов, какието мудреные схемы хз
zustand прост и асинхронен. Можно передавать кастомную ф-цию сравнения изменений. Но, как комбайнить, если много функционала в связанной фиче? Slices Pattern в доках не открывается
Спасибо за ролик! Возникает несколько вопросов 1 с чего вы взяли, что mobx - state manager? Он ничего общего к state management не имеет! State manager - это mobx state tree. Mobx - это библиотека для работы с observable структурами 2 честно сказать, zustand выглядит как хорошая штука для маленьких pet projects. Использование его в enterprise решениях вызывает ряд вопросов: Как отделить доменную логику от бизнес логики? Как отделить слой репозиториев? Почему вообще инструмент работы с данными должен быть вмонтирован в react?
Привет :) 1. Когда открываешь npm Mobx там первая фраза "Simple, scalable state management." 2. В моей парадигме стор это не место для любой логики, это лишь set / get хранилище. В итоге у меня есть хорошее решение как я отделяю это все 3. Инструмент не вмонтирован в React, я не показывал пример в ролике, что с ним можно работать напрямую как с любым стором. Это дэфолт для любого стора
А в чем отличие доменной логики от бизнес логики? Зушьтанд вроде как мультистор, поидее делишь сторы как тебе нужно и все? Ну или я мож чего-то не понимаю. Про слои можно fsd глянуть. mobx можно назвать стейт менеджером, но если сравнивать с redux tookit или mobx state tree то согласен что он более низкоуровневый и в первую очередь это просто либа с адекватным механизмом реактивности в замену реактовскому подходу.
@@it-sin9k 3. У zustand 2 api для создания сторов: - createStore без привязки к react. - create, который использует под капотом useSyncExternalStore из react, чтобы работал ререндер на изменение состояния.
У меня к zustand лишь одна претензия - ооочень сильная завязка на react. Использование сторов вне компонентов неудобное, из-за чего есть проблема с вынесением бизнес логики в отдельные сервисы. Приходится все равно все закручивать вокруг react компонентов, из-за чего ui и логика очень тесно связываются Мне было бы интересно посмотреть на упомянутый в видео способ работы с асинхронными action-ами, очень жду!:)
Почему-то, при сравнении какого-нибудь стейт-менеджера с Redux, подразумевается самый первый вариант его использования из 2015. А если ещё убрать асинхронные экшены, как предлагается в видео, то отличий будет совсем немного.)
После MobX Zustand не зашёл вообще. Очень многословен и нет нормальных компьютедов. Кажется, что когда (и если) в JS дотащат сигналы, такой подход будет более распространён.
Когда у вас на проекте много джунов или проект достаточно маленький - зустанд хороший выбор. Но если мозг не уровня рыбки (я про порог входа) и вам нужно стабильное решение, проверенное временем, с возможностью нормализации данных (entityAdapter), описания сайдэффектов(extraReducers, listener middleware), в т.ч. интеграции вашего стора с работой с апи (rtk query: инвалидация + те же extraReducers + middleware), то как показывает практика ваш выбор - rtk
я игрался с zustand не понравилось пару моментов: 1) то что есть доступ к методам редюсера и ты можешь их переопределить 2) то что из-за отсутствия провайдера с асинхронным перзистом происходит 2 рендера вначале, первыр раз дефолтный стор, а второй уже подгруженный из перзиста
Болею за zustand, хоть в вакансиях его и не встречал (рб), не знаю даже, почему многие до сих пор сидят на redux, а еще и thunk и тд. и тп., а еще пишут "нет легаси", ну ну :), просто нет желания переписывать, вот и тянут. Bear is here!
Redux не уйдет в прошлое как минимум из-за огроменного легаси кода на нем. Тем более компаниям нет смысла переходить на zustand, потому что редакс вообще не устарел. Более сложный, более громоздкий во всех смыслах, но все еще рабочий. Так что сомневаюсь, что в крупных компаниях будут переходить на него. Хотя я полностью за zustand, намного удобнее редакса всех видов
мы затаскивали Zustand в проект с 100к плюс/минус уникальными посетителями каждый день, не знаю можно считать это большим проектом или нет, но, честно говоря, ни разу не пожалели о своём выборе. Даже когда добирали сотрудников на проект. они говорили. что не знают Zustand, но стоило им посмотреть код, их обратный фидбек был в том, что как всё просто и понятно.
Размер проекта измеряется не в количестве уникальных пользователей, а в присутствии огромного количества сложной логики, кучи стейтов и экранов в приложении)
"...но я постораюсь втянуть его в свои проекты и изучить" потом добавлю строчку в резюме и побегу за новым оффером, чтобы не решать проблемы, которые возникли в проекте из-за добавления в него новой ненужной там перды
в моем банке добавляли зустанд, сделали много ошибок при работе с ним. Полный запрет на асинхронный код - вот тут верно, мы не вовремя это поняли и многие куски кода пришлось перепиливать, *persist добавлял на пару страниц, но я не совсем успел попробовать на более сложных вещах (увольнялся из-за маленькой зп). В целом зустан заслуживает первое место в проектах. Щас работаю в другом проекте и использую редакс и честно скажу - зустан не победит редакс! у него другая архитектура и подход к проектам, что заменить редакс на зустанд будет ой как не просто
не хватает конечно примеров с typescript, и расскажи пожалуйста про эти свои абстракции для async запросов, учитывая что react query ты, судя по видео про него, не рекоммендуешь
Согласен с вами на 100%. Перешёл на него после mobx. Лёгкий, быстрый, понятный. Есть persist, framework-agnostic и можно использовать даже в Vanilla Js. Не понимаю популярности redux - его время уже давно прошло, даже, если использовать RTK. В чём смысл писать, условно, 10 строк, если можно обойтись 2-3? Все эти цуштанды, jotai и т.п. чересчур кривые и многословные по сравнению с nano stores. Не понимаю также пиара всякого шлака вроде effector или, прости господи, reatom в русскоязычном коммьюнити
Немного смущает размазывание логики на множество независимых сторов. Не будет ли тяжело прокидывать preloadedState по множеству независимых сторов? Как реализовать взаимодействие/общение между этими сторами?
Если относится к сторам, как к хранилищам данных и не более. Тогда общения между ними никакого нет, 2 стора делают только get / state. А дальше это не сторов обязанность :)
@@it-sin9k , спасибо за ответ. Но мой поинт не в этом. Я про сложность использования множества независимых сторов. Ок, можно не хранить логику в сторе, превратив его в простой объект с единой задачей "get/set value" (правда, где тогда хранить логику, которая обычно лежит в санках/сагах). Остаётся prerender state. Я был немного в шоке от примера по интеграции с Next.js на официальном сайте с оборачиванием каждого стора в отдельных контекст. Плюс, не очень понятна логика селекторов, когда компоненту нужно вытащить данные из двух сторов. Можно взять пример из твоего видео по Event bus, где было необходимо останавливать запись голосового сообщения при звонке. В рамках Redux это решается довольно легко: выносим обе переменные в Redux и одним селектором достаем нужное компоненту "computed" значение `const allowRecording = useSelector((store) => store.voiceRecorder.isRecording && !store.callManager.hasCall)`. В таком случае количество сторов, которые поставляют условия может быть каким угодно, при этом количество перерендеров - минимальным. А с Zustand придётся вызывать useCallManagerStore и useVoiceRecorderStore, подписываясь на ненужные изменения.
ну да тут схема такая что компонент является связующим звеном между сторами если надо, но мне не требовалось пока. под каждый модуль свой стор просто и они изолированы
@@NeoCoding, но тогда у компонентов образовывается слишком много ответственности. Если стор умеет только отдавать/записывать данные, получается, компонент должен знать про сторы, про фетч данных, про обработку этих данных и потенциальных ошибок. Это не особо хорошо выглядит на фоне других решений вроде Redux или Effector, где все логика разделена между сторами/слайсами, а компоненты вообще не знают этих деталей. Просто подписываются на изменения данных / диспатчат экшены/события.
@@fav7575 да наверное. у меня на относительно несложном проекте отношения со стором в основном модуль - стор. прочитал - записал. все вычисления над данными идут в утилитах, которые подключены вызываются в слайсе, результат вычисления просто кладётся в нужное поле стора. логические связи внутри компонентов тоже есть, куда без этого, всё же логика завязана на ui. В принципе можно было бы сделать один стор на весь проект, но мы пошли по пути создания отдельного стора на каждую страницу, так из удобства работы - громадный стор не так удобно обслуживать.
У jotai самый критичный недостаток для меня был в том, что нельзя читать и изменять значения атомов вне компонентов реакта, в отличие от zustand. А так в остальном показалось лучше.
Еще не понятно, зачем так демонизировать mobx? Та схема, что там приводится - это жизненный цикл observable данных. Он необходим, чтобы понимать, что ща чем обновляется. Иначе все превращается в магию. От декораторов там давно отказались. Все что нужно, это в конструкторе makeObservable написать и все. Писать классы , это, как мне кажется, более js next way, чем писать объекты. Так же, mobx весьма неплохо подходит для описания сложных состояний отдельных компонентов. Я через mobx реализовал чистую архитектуру, чем очень доволен и использую данный подход уже 5 лет
Нет у меня цели демонизировать MobX :) Это лишь факты, я открыл главные страницы разных менеджеров и сравнивал, насколько быстро можно войти в эту реку. И эта таблица в самом начале. Я так же с ним работал, и знаю, что означают эти графики. А по поводу чистой архитектуры, я все же сторонник, что архитектура не должна сильно зависеть от инструментов. Я тоже во времена работы с MobX свой вариант архитектуры организовал, и благодаря отсутсвию зависимости на инструменты на Redux проектах, тоже смог ей пользоваться и на zustand не вижу никаких проблем прикрутить
Не любитель флюксов, но если выбирать между ними то zustand показался самым простым для использования на первый, поверхностный взгляд. Популярность мне кажется именно этим и обоснована. Но простое для вхождения не значит лучшее, особенно если в проекте есть хоть какая-то сложность. Пока присматриваюсь к mobx. Redux люто ненавижу
Если хотите показать свое никчемное чсв, то да, ни в коем случае не делайте асинхронные методы в сторе, никогда. А еще делайте как можно больше ненужных абстракций над абстракциями, которыми будете пользоваться ровно НОЛЬ раз. Ведь это же так круто, когда на простом проекте становится 10+ миллионов строк кода
Привет Саш! Спасибо за видео. Хотел добавить что прокаченный zustand это Valtio, где селекторы уже встроенные и можно делать простую деструктуризацию без шаллоу.
Не понял, почему он на хайпе? чем лучше мобх? Мобх кеширует компоненты , синтаксис использования удобный, кому надо есть автораны и прочие фишки . А в цуштанде что есть ?
Медведьштанд это редукс только проще в тыщу раз, без лишних сложностей. А т.к. вся индустрия использует и молится на редукс и функциональное программирование - по этому все и радуется что он такой простой по сравнению с редкусом. А сложный код никто не пишет как будто. Это мое мнение
В zustand можно подписаться на изменение состояния, аналогично как в реакции из mobx. Но большой плюс mobx - это, конечно, возможность напрямую мутировать состояние
А каким образом разрабы должны научиться это делать? Откуда мне знать, что это немецкое слово и правильно произносить Цуштанд ? Единственные гении это Vite, которые прям в доке и написали произношение)
@@alnazarov включить мозги это выучить немецкое произношение ради того чтобы наверняка знать как произносится название библиоткеки? нет уж, лучше другим займусь
Не ради холивара: в Redux есть важная фича - экшены. Если мне нужно по одному экшену в разных сторах, например нужно изменение состояния в модулях, при изменении данных в глобальном состоянии (и даже может быть наоборот, чего только бизнес не попросит), то я просто импортирую экшен, который уже передает пропсы нужные и вот я уже в зависимости от них строю логику. На долгом пути такой кейс ой как оказался полезен. В Mobx же для такого кейса придется связывать отдельные сторы посредством прослоек из хуков, либо изменять один стор внутри другого стора, ну или в самом компоненте, тут каждый сам себе художник (нет). Вот интересно как связать несколько сторов в Zustand путем написания одного экшена, при этом не исключая возможности использовать этот экшен в будущем и для других сторов уровнем выше\ниже или соседние, как это имеет Redux со своими сложными редукторами -_-
как заходит дело дальше примеров для инкремента счетчика, так сразу начинается обмазывание колбэками и прочей лабудой... жаль. "неочевидных прокси оберток" - странно слышать от автора, который вроде как по js же контент пилит. даже интересно, что неочевидно в Proxy? "низкий порог вхождение" - это уже должно звучать как минус. Потом такие проекты после отряда джунов нереально поддерживать. "мобикс можно написать 10 способами" = "чтобы уметь пользоваться мобикс, надо книжки читать" = "высокий порог вхождение" - так то это плюс, код всяко лучше будет выглядеть, чем написанный теми, кому хватило примеров инкремента счетчиков. за контент спасибо!
Крайне сомнительная конструкция вами описана > "мобикс можно написать 10 способами" = "чтобы уметь пользоваться мобикс, надо книжки читать" = "высокий порог вхождение" Мы приходим на работу, чтобы решать бизнес задачи, а не учить инструменты. И завтра новый чел, должен вникнуть в твою кодовую базу и снова приносить value для компании. И вроде как низкий порог вхождения === экономия для бизнеса === однозначно плюс
@@it-sin9k Только вот, есть одно но. Низкий порог вхождения, чаще всего, равен низкой профессиональности. Программист с высокими проф навыками приносит больший Value, и его код не превратится во время поддержки в x10 по деньгам для бизнеса
@@it-sin9kэто база. Почему-то многие погроммисты забывают, что их задача код писать, который будет зарабатывать деньги. И желательно, чтоб другие макаки этот код понимали, от мала до велика.
"Для меня Zustand стал стейт менеджером номер 1"
"Я ни разу не использовал его в продакшене"
Синяк наваливает базу
первое скорее про эмоции, а второе по фактам))
Да, та же ситуация наверное у большинства людей
Было бы интересно узнать про то как лучше работать с async методами, про какие абстракции в архитектуре идет речь, было бы интересно узнать)
Обязательно об этом расскажу позже)
стор должен хранить в себе данные и иметь возможность их изменять, он не должен вызывать side-эффекты при вызове какого-нибудь действия. Стор - это просто состояние. Асинхронный код должен вызываться вне стора, совершенно отдельно.
Например у тебя есть форма, при её сохранении ты хочешь отправить запрос на сервер, а потом записать что-то (например вернувшийся id, хз) в стор, то вместо того, чтобы делать запрос в действии стора, следует сделать запрос просто в обычной ф-ии, а по его завершении вызвать, например setObjectId() из стора.
+
Интересно узнать, синяк, где у тебя в проекте асинхронные запросы.
@@MrREALball а что мешает исполнять асинхронный код в сторе? Кроме «традиций»😅
Если библиотека это позволяет.
@@MaksTrueman масштабируемость, например. Это банальное разграничение зон ответственности и если его не будет - будет страдать масштабируемость, будет сложнее вводить новых сотрудников в курс дела и следить за тем, чтобы они не косячили
Zustand уже встречается в вакансиях вместо Redux, а значит его активно используют в продакшене. И это хорошо, потому что Redux надо давно хоронить.
Согласен редаксу пора на пенсию.
с последних проектов, с которыми сталкивался, складывается впечатление, что редакс выбирают чисто из-за работы с привычным стеком, который себя вроде как зарекомендовал в прошлом
но после того, как на одном из проектов заменил ядерную комбинацию redux-toolkit + saga (засетапленную не мной), на zustand + react-query, понял, что скорость выполнения задач возросла в разы и особого смысла в редаксе уже как бы и нету имхо
да, можно спорить про архитектурные моменты, разделение кода и ответственности и бла-бла-бла, но по факту проект, который сейчас разросся до огромного приложения, отлично себя чувствует на рельсах зустанда
вот кое-что на вентилятор и, возможно, "на обсудить" - некоторые "архитектурные" принципы возникли из-за редакса и теперь просто не налезают на современные тулзы вроде зустанда, т.к. просто не нужны :)
Сегодня буквально смотрел проектик, помочь нужно, там тоже стэк redux-toolkit + saga. ЗАчем вообще saga, если в toolkit уже встроен RTK Query?? Т.е. выбор zustand + react-query просто отсеял redux :Ъ А вот концепции saga не понял, но с ней и не работал никогда, может и есть чего ультраимбового
@@bebeto123g ультрабойлерплейт наподобие старого редакса =)) забавно что поверх саг даже либу написали для минимизации однотипных действий (redux-saga-routines)
@@bebeto123g и я о том же) выдохнул с огромнейшим облегчением после переезда на zustand)
А потом ты узнаешь что и zustand не особо нужен, да и react-query можно тоже в целом выкинуть
@@bebeto123g редакс + сага это жесть. Код больше на крякозябры похож. Что это за оптимизация кода, когда код невозможно читать)
Redux сейчас идёт вместе с rtk-query . Zustand, наверное, придется использовать с react-query. Было бы интересно сравнить удобство пользования и размер
Главное их не смешивать. Видел дичь, когда люди делают запросы через react-query и сохраняют сетевой кеш внутри zustand :) Т.е. полное непонимание смысла react-query.
По своему опыту скажу, что удобнее rtk-query, тем более, что в комплекте идёт state и в этом есть плюсы при взаимодействии. По размерам, написал в недавнем посте)
@@АлександрВолков-о8ю мне кажется react query намного проще. вот допустим на нем вообще легко сделать infinite query, а в rtk query чет нужно самому придумывать и возиться с этим..
@@АлександрВолков-о8ю я ни разу не работал с rtk-query, на проектах используем @tanstack/query + zustand/mobx, но посмотрев на примеры кода в документации, я не могу представить ситуацию, в которой мы хоть на одном нормальном продакт решении попробуем это вместо @tanstack/query.
Конечно ради саморазвития я попробую что-нибудь сварганить с помощью него, но выглядит это как просто ненужное нагромождение всего и вся.
В китченсинке вообще получается что rtk - это ещё и замена стандартного fetch/axios. А что, если меня fetch устраивает? А что, если у меня вообще запрос ни к апи делается, а к веб воркеру например (с помощью щепотки магии)?
Не знаю, может я просто слишком сильно отдалился от концепции глобальных состояний (в частности благодаря @tanstack/query & react-hook-form), но всё это выглядит абсолютно необязательным, да ещё и сильно повышает порог входа в проект.
Конечно, разобраться с этим можно за пару часов, при желании, но я просто реально не понимаю: зачем? В чём преимущество такого подхода? Масштабируемость? Нет, огромный монорепозиторий с кучей модулей спокойно работает и без этого и, скорей всего, с меньшим coupling'ом.
Необходимость? Непонятно в чём заключается.
Удобство? Тоже не понятно где.
Использую в новом проекте Zustand и react-query, это лучшее что со мной происходило за последнее время )))
О, это Вы еще значит не знаете про Valtio :-) вот эта мне реально понравилась. Особенно то что оно работает как для React'а, так и для Vanilla. Т.е. я могу снаружи изменить стейт и компонент перерисуется, плюс я гонял его на SSR и на клиенте, прекрасно работает.
У меня был опыт с Zustand для SPA приложения. Крайне положительный опыт: нулевой порог вхождения, легковесный, никакого бойлерплейта
использовать можно в простых случаях, когда только прочитать записать в модуле, просто как некий более глобальный стейт для модуля и компонентов, какието мудреные схемы хз
Давай про эффектор очень интересно послушать твое мнение
Хорошо) запишу)
чтобы рассказывать про effector(как в целом про любую технологию) с ним надо сначала поработать, иначе ценность мнения равна нулю
Как дела у zustand с тестированием (моки) и дебагом (можно ли и удобно ли смотреть текущий стейт в инспекторе)?
В плане дебага- да, можно. Они юзают redux devtools :)
В доке описано как добавить. Буквально импорт + доп обертка над create
zustand прост и асинхронен. Можно передавать кастомную ф-цию сравнения изменений. Но, как комбайнить, если много функционала в связанной фиче? Slices Pattern в доках не открывается
Цуштанд очень хорош, но мы используем preact-signals.
Тож думал юзать сигналы эти, но в итоге решил юзать mobx, т.к. там было то что искал в +- удобном и понятном виде
Спасибо за ролик!
Возникает несколько вопросов
1 с чего вы взяли, что mobx - state manager? Он ничего общего к state management не имеет! State manager - это mobx state tree. Mobx - это библиотека для работы с observable структурами
2 честно сказать, zustand выглядит как хорошая штука для маленьких pet projects. Использование его в enterprise решениях вызывает ряд вопросов:
Как отделить доменную логику от бизнес логики?
Как отделить слой репозиториев?
Почему вообще инструмент работы с данными должен быть вмонтирован в react?
Привет :)
1. Когда открываешь npm Mobx там первая фраза "Simple, scalable state management."
2. В моей парадигме стор это не место для любой логики, это лишь set / get хранилище. В итоге у меня есть хорошее решение как я отделяю это все
3. Инструмент не вмонтирован в React, я не показывал пример в ролике, что с ним можно работать напрямую как с любым стором. Это дэфолт для любого стора
А в чем отличие доменной логики от бизнес логики? Зушьтанд вроде как мультистор, поидее делишь сторы как тебе нужно и все? Ну или я мож чего-то не понимаю. Про слои можно fsd глянуть. mobx можно назвать стейт менеджером, но если сравнивать с redux tookit или mobx state tree то согласен что он более низкоуровневый и в первую очередь это просто либа с адекватным механизмом реактивности в замену реактовскому подходу.
@@it-sin9k
3. У zustand 2 api для создания сторов:
- createStore без привязки к react.
- create, который использует под капотом useSyncExternalStore из react, чтобы работал ререндер на изменение состояния.
Зустанд уже опередил редакс тулкит по скачиваниям в нпм
Спасибо за работу
Юзали цуштанд последние 2 года на всех своих новых проектах, все нравится, все круто!
я сам пользуюсь zustand, хочу сказать что это удобно чем redux с своими RTK Query
Слава богу)) я думал ты уже в инсту перешел😊
ахахах) на самом деле мы работаем над проектиком одним в фоне для Синяка)
Нормальное браузерное расширение, от которого не идет кровь из глаз, есть только у Redux/toolkit, следовательно его никто не победит.
Создатель либы японец Диши Като произносит зустанд как Зустанд, так что все норм) не слушай всяких цуштандов )
ахахах) спасибо за поддержку!)
Как из ничего сделать видос на 8 минут))) спасибо, что почитал доку за меня
Всегда к твоим услугам)
У меня к zustand лишь одна претензия - ооочень сильная завязка на react. Использование сторов вне компонентов неудобное, из-за чего есть проблема с вынесением бизнес логики в отдельные сервисы. Приходится все равно все закручивать вокруг react компонентов, из-за чего ui и логика очень тесно связываются
Мне было бы интересно посмотреть на упомянутый в видео способ работы с асинхронными action-ами, очень жду!:)
да, классный стейт менеджер, где есть реакт 18
Почему-то, при сравнении какого-нибудь стейт-менеджера с Redux, подразумевается самый первый вариант его использования из 2015.
А если ещё убрать асинхронные экшены, как предлагается в видео, то отличий будет совсем немного.)
А что с Redux Toolkit? Он вроде и работает, но без redux store не то.
После MobX Zustand не зашёл вообще. Очень многословен и нет нормальных компьютедов. Кажется, что когда (и если) в JS дотащат сигналы, такой подход будет более распространён.
Когда у вас на проекте много джунов или проект достаточно маленький - зустанд хороший выбор.
Но если мозг не уровня рыбки (я про порог входа) и вам нужно стабильное решение, проверенное временем, с возможностью нормализации данных (entityAdapter), описания сайдэффектов(extraReducers, listener middleware), в т.ч. интеграции вашего стора с работой с апи (rtk query: инвалидация + те же extraReducers + middleware), то как показывает практика ваш выбор - rtk
Можно использовать Zustand с React Query. Я так делаю в нескольких проектах. Более чем доволен.
Похоже на pinia)
я игрался с zustand не понравилось пару моментов:
1) то что есть доступ к методам редюсера и ты можешь их переопределить
2) то что из-за отсутствия провайдера с асинхронным перзистом происходит 2 рендера вначале, первыр раз дефолтный стор, а второй уже подгруженный из перзиста
Народ, че думаете на счет jotai?
Уже победил
Цуштанд
цпшухжктанд
04:05 - я сразу и не понял что такое: нацы хани
ахахах)
Как Харе Кришна, только Нацы Хани
В целом, похож на эффектор и немного на рекоил
Нет чел, присмотрись. Он похож на МЕДВЕДЯ
Болею за zustand, хоть в вакансиях его и не встречал (рб), не знаю даже, почему многие до сих пор сидят на redux, а еще и thunk и тд. и тп., а еще пишут "нет легаси", ну ну :), просто нет желания переписывать, вот и тянут. Bear is here!
Да мне кажется просто потому что это шаблон, а по шаблону проще. Всех кого спрашивал его не особо обожают)
ЦуштАнд…
ща бы в 2024 сравнивать килобайтики либ
люблю спички считать)
Redux не уйдет в прошлое как минимум из-за огроменного легаси кода на нем. Тем более компаниям нет смысла переходить на zustand, потому что редакс вообще не устарел. Более сложный, более громоздкий во всех смыслах, но все еще рабочий. Так что сомневаюсь, что в крупных компаниях будут переходить на него. Хотя я полностью за zustand, намного удобнее редакса всех видов
Согласен) тут скорее новые проекты будут чаще начинаться не на redux
А потом вдруг… приложение сложнее чем привет мир.. и оказывается что есть проблемы с оптимизацией:/
что за проблемы?)
А как теперь всё это добро тестировать?
Да вроде не сложнее чем redux
Тесты для неуверенных в себе. Нормальные разработчики сразу без багов пишут
@@jgkdmdevienjjgg8866гы
мы затаскивали Zustand в проект с 100к плюс/минус уникальными посетителями каждый день, не знаю можно считать это большим проектом или нет, но, честно говоря, ни разу не пожалели о своём выборе.
Даже когда добирали сотрудников на проект. они говорили. что не знают Zustand, но стоило им посмотреть код, их обратный фидбек был в том, что как всё просто и понятно.
спасибо за подробный фидбек!)
Размер проекта измеряется не в количестве уникальных пользователей, а в присутствии огромного количества сложной логики, кучи стейтов и экранов в приложении)
@@cassra8289 или кол-во кода, или кол-во сотрудников на проекте, или еще чего-то. С чего вы решили, чтобольшой проект это именно то, что вы написали?
"...но я постораюсь втянуть его в свои проекты и изучить"
потом добавлю строчку в резюме и побегу за новым оффером, чтобы не решать проблемы, которые возникли в проекте из-за добавления в него новой ненужной там перды
Надо по-немецки произносить "Цуштанд". Так круче ;) Zustand переводится с немецкого как "состояние"
Так не круче, так правильно. :)
in addition to persist: you can store your values as url search/hash params and control store hidration
После видео я пошел изучать зустанд через доку, уже зная редакс/тулкит. Выучил за 3 часа все что нужно, спасибо за мотивацию ❤
в моем банке добавляли зустанд, сделали много ошибок при работе с ним. Полный запрет на асинхронный код - вот тут верно, мы не вовремя это поняли и многие куски кода пришлось перепиливать, *persist добавлял на пару страниц, но я не совсем успел попробовать на более сложных вещах (увольнялся из-за маленькой зп).
В целом зустан заслуживает первое место в проектах.
Щас работаю в другом проекте и использую редакс и честно скажу - зустан не победит редакс! у него другая архитектура и подход к проектам, что заменить редакс на зустанд будет ой как не просто
Удивительно как до реакт коммьюнити долго доходит, что они делают какую-то чушню
не хватает конечно примеров с typescript, и расскажи пожалуйста про эти свои абстракции для async запросов, учитывая что react query ты, судя по видео про него, не рекоммендуешь
да) у меня есть альтернатива) поделюсь ей позже)
Неплохо бы ещё затронуть аспект дебага.
в документации есть пример интеграции с redux devtools
Для меня номер 1 пока что nanostore.
Хотя этот zustand тоже малeнький вроде
не слышал о таком) надо будет посмотреть)
@@it-sin9kдетище андрея ситника вроде
Согласен с вами на 100%. Перешёл на него после mobx.
Лёгкий, быстрый, понятный. Есть persist, framework-agnostic и можно использовать даже в Vanilla Js.
Не понимаю популярности redux - его время уже давно прошло, даже, если использовать RTK. В чём смысл писать, условно, 10 строк, если можно обойтись 2-3?
Все эти цуштанды, jotai и т.п. чересчур кривые и многословные по сравнению с nano stores. Не понимаю также пиара всякого шлака вроде effector или, прости господи, reatom в русскоязычном коммьюнити
Очень странно, что nano stores не обладает в данный момент должной узнаваемостью. На мой взгляд, это один из лучших state-менеджеров сейчас
Zustand топ👍 после редакса как глоток свежего воздуха. И с next js на app router подружился легко
Верю, что победит
А какие щас бест практис, чтобы делать HTTP запросы?
если некст то через фетч на серверных компонентах. или useSWR rtq на клиентских
recoil еще лучше 😂
ЦУШТАНД, ну епана
Немного смущает размазывание логики на множество независимых сторов. Не будет ли тяжело прокидывать preloadedState по множеству независимых сторов? Как реализовать взаимодействие/общение между этими сторами?
Если относится к сторам, как к хранилищам данных и не более. Тогда общения между ними никакого нет, 2 стора делают только get / state. А дальше это не сторов обязанность :)
@@it-sin9k , спасибо за ответ. Но мой поинт не в этом. Я про сложность использования множества независимых сторов. Ок, можно не хранить логику в сторе, превратив его в простой объект с единой задачей "get/set value" (правда, где тогда хранить логику, которая обычно лежит в санках/сагах). Остаётся prerender state. Я был немного в шоке от примера по интеграции с Next.js на официальном сайте с оборачиванием каждого стора в отдельных контекст. Плюс, не очень понятна логика селекторов, когда компоненту нужно вытащить данные из двух сторов. Можно взять пример из твоего видео по Event bus, где было необходимо останавливать запись голосового сообщения при звонке. В рамках Redux это решается довольно легко: выносим обе переменные в Redux и одним селектором достаем нужное компоненту "computed" значение `const allowRecording = useSelector((store) => store.voiceRecorder.isRecording && !store.callManager.hasCall)`. В таком случае количество сторов, которые поставляют условия может быть каким угодно, при этом количество перерендеров - минимальным. А с Zustand придётся вызывать useCallManagerStore и useVoiceRecorderStore, подписываясь на ненужные изменения.
ну да тут схема такая что компонент является связующим звеном между сторами если надо, но мне не требовалось пока. под каждый модуль свой стор просто и они изолированы
@@NeoCoding, но тогда у компонентов образовывается слишком много ответственности. Если стор умеет только отдавать/записывать данные, получается, компонент должен знать про сторы, про фетч данных, про обработку этих данных и потенциальных ошибок. Это не особо хорошо выглядит на фоне других решений вроде Redux или Effector, где все логика разделена между сторами/слайсами, а компоненты вообще не знают этих деталей. Просто подписываются на изменения данных / диспатчат экшены/события.
@@fav7575 да наверное. у меня на относительно несложном проекте отношения со стором в основном модуль - стор. прочитал - записал. все вычисления над данными идут в утилитах, которые подключены вызываются в слайсе, результат вычисления просто кладётся в нужное поле стора. логические связи внутри компонентов тоже есть, куда без этого, всё же логика завязана на ui. В принципе можно было бы сделать один стор на весь проект, но мы пошли по пути создания отдельного стора на каждую страницу, так из удобства работы - громадный стор не так удобно обслуживать.
Зустанд топ
Valtio топчик!
Ну тогда давай ещё и про Jotai (zustand 2.0?)
Не слышал про такой) надо смотреть)
@@it-sin9k причем они от одного и того же мейнтейнера. Только zustand больше про глобальный стор, а jotai про атомный..
У jotai самый критичный недостаток для меня был в том, что нельзя читать и изменять значения атомов вне компонентов реакта, в отличие от zustand. А так в остальном показалось лучше.
Jotai - это не зустанд 2.0 🤣 они примерно в одно время появились. Хоть и очень похожи, но зустанд всё-таки удобнее и выиграл маркетинговую гонку
Зустанд - хорош. Очень удобно им пользоваться
Топ) смотрю в основном хорошие отзывы)
Как всегда коротко, по делу и ясно! Спасибо!
Еще не понятно, зачем так демонизировать mobx?
Та схема, что там приводится - это жизненный цикл observable данных. Он необходим, чтобы понимать, что ща чем обновляется. Иначе все превращается в магию.
От декораторов там давно отказались. Все что нужно, это в конструкторе makeObservable написать и все.
Писать классы , это, как мне кажется, более js next way, чем писать объекты.
Так же, mobx весьма неплохо подходит для описания сложных состояний отдельных компонентов.
Я через mobx реализовал чистую архитектуру, чем очень доволен и использую данный подход уже 5 лет
Mobx не поддерживается react compiler
Нет у меня цели демонизировать MobX :) Это лишь факты, я открыл главные страницы разных менеджеров и сравнивал, насколько быстро можно войти в эту реку. И эта таблица в самом начале. Я так же с ним работал, и знаю, что означают эти графики.
А по поводу чистой архитектуры, я все же сторонник, что архитектура не должна сильно зависеть от инструментов. Я тоже во времена работы с MobX свой вариант архитектуры организовал, и благодаря отсутсвию зависимости на инструменты на Redux проектах, тоже смог ей пользоваться и на zustand не вижу никаких проблем прикрутить
Большое спасибо за ответ!
@@Graphouny77 не фанат mobx но как будто бы это проблемы реакт компайлера а не самого mobx
@@Graphouny77 react compiler, как оказалось, практически ничего не может
Не могу нигде найти: есть ли в zustand нормализация данных, как в redux?
год назад затягивал на проект, в целом работает.
единственное в сообществе реакт в телеге не упоминайте, а то там какахами закидают грамотеи😂
сравнивать RTK и Zustand по килобайтам.... ну такое... такое...
спасибо большое! Интересно, как они под капотом оборачивают твоё приложение в контекст собственный или как по другому?
Не любитель флюксов, но если выбирать между ними то zustand показался самым простым для использования на первый, поверхностный взгляд. Популярность мне кажется именно этим и обоснована. Но простое для вхождения не значит лучшее, особенно если в проекте есть хоть какая-то сложность. Пока присматриваюсь к mobx. Redux люто ненавижу
rtk он не обгонит скорей всего, если он не станет ztk xD
Если хотите показать свое никчемное чсв, то да, ни в коем случае не делайте асинхронные методы в сторе, никогда. А еще делайте как можно больше ненужных абстракций над абстракциями, которыми будете пользоваться ровно НОЛЬ раз. Ведь это же так круто, когда на простом проекте становится 10+ миллионов строк кода
Привет Саш! Спасибо за видео. Хотел добавить что прокаченный zustand это Valtio, где селекторы уже встроенные и можно делать простую деструктуризацию без шаллоу.
надо изучать) спасибо!)
Жду обзор Valtio vs Zustand
а еще есть Jotai, и все эти три делает одна команда и все они с разных языков переводятся как "состояние" 😊
произносится как зуштанд
Тогда уж Цуштанд, коли по-немецки
Ходил на собеседование в нидерландскую компанию, они говорят зустанд, никаких проблем. У них немецкий родной, если что)
Все-таки это немецкий, поэтому надо читать ЦуШтанд
Я за 2 года редакс использовал 1 или 2 раза и это было совсем не весело
Спасибо за видосы. Инсту тоже чекам -_-
спасибо за познавательный видос!
❤
До сих добавляете качественные субтитры, я тогда просил добавить сабы давно, до сих пор прислушались, огромное спасибо )
рад) что до сих пор делаем это не зря))
Интересно получилось бы сложному проекту на редакс сага перейти на Zustand + react query?
тут надо смотреть, насколько вы замазаны перемазаны сагой и редаксом)
Лайк в поддержку канала
Lerne Deutsch!
effector же
надо и на него обзор сделать)
при размерах проектов в мегабайты считать разницу в десять килобайт?
так проекты и становятся мегабайтными, потому что никто не считает килобайты)
@@it-sin9k так если кода не одна тысяча строк. подключаемые библиотеки меркнут на фоне кода самого проекта.
Не понял, почему он на хайпе? чем лучше мобх?
Мобх кеширует компоненты , синтаксис использования удобный, кому надо есть автораны и прочие фишки .
А в цуштанде что есть ?
Медведьштанд это редукс только проще в тыщу раз, без лишних сложностей. А т.к. вся индустрия использует и молится на редукс и функциональное программирование - по этому все и радуется что он такой простой по сравнению с редкусом. А сложный код никто не пишет как будто. Это мое мнение
В zustand можно подписаться на изменение состояния, аналогично как в реакции из mobx. Но большой плюс mobx - это, конечно, возможность напрямую мутировать состояние
не зусианд а ЦУШТАНД!
этотна немецком
спасибо)
Ксиаоми
нейронкой озвучивал?
Это его оригинальный голос 😂
@@mrstronciy1060 не, зустанд нейронка произносит
наверное, лет 200 пройдет до того времени, как все разрабы научатся правильно произносить Zustand
А каким образом разрабы должны научиться это делать? Откуда мне знать, что это немецкое слово и правильно произносить Цуштанд ? Единственные гении это Vite, которые прям в доке и написали произношение)
@@BigMother228 включайте мозги и просвещайтесь, а не только буковки на экране читайте
Как по мне душновато это)
Всего знать невозможно, да и произношение все таки не играет роли как работает та или иная штука)
@@alnazarov включить мозги это выучить немецкое произношение ради того чтобы наверняка знать как произносится название библиоткеки? нет уж, лучше другим займусь
спасибо за видео! zustand действительно крут и пользоваться им одно удовольствие, без ноток мазохизма как с тем же mobX или redux
первое впечатление именное такое же)
Не ради холивара: в Redux есть важная фича - экшены. Если мне нужно по одному экшену в разных сторах, например нужно изменение состояния в модулях, при изменении данных в глобальном состоянии (и даже может быть наоборот, чего только бизнес не попросит), то я просто импортирую экшен, который уже передает пропсы нужные и вот я уже в зависимости от них строю логику. На долгом пути такой кейс ой как оказался полезен. В Mobx же для такого кейса придется связывать отдельные сторы посредством прослоек из хуков, либо изменять один стор внутри другого стора, ну или в самом компоненте, тут каждый сам себе художник (нет). Вот интересно как связать несколько сторов в Zustand путем написания одного экшена, при этом не исключая возможности использовать этот экшен в будущем и для других сторов уровнем выше\ниже или соседние, как это имеет Redux со своими сложными редукторами -_-
Что по Zustand + Next?
честно говоря не знаю
@@it-sin9kна сколько я знаю у zustand в общем все не хорошо с SSR
да норм работет так же, но на клиентских
как заходит дело дальше примеров для инкремента счетчика, так сразу начинается обмазывание колбэками и прочей лабудой... жаль.
"неочевидных прокси оберток" - странно слышать от автора, который вроде как по js же контент пилит. даже интересно, что неочевидно в Proxy?
"низкий порог вхождение" - это уже должно звучать как минус. Потом такие проекты после отряда джунов нереально поддерживать.
"мобикс можно написать 10 способами" = "чтобы уметь пользоваться мобикс, надо книжки читать" = "высокий порог вхождение" - так то это плюс, код всяко лучше будет выглядеть, чем написанный теми, кому хватило примеров инкремента счетчиков.
за контент спасибо!
Крайне сомнительная конструкция вами описана
> "мобикс можно написать 10 способами" = "чтобы уметь пользоваться мобикс, надо книжки читать" = "высокий порог вхождение"
Мы приходим на работу, чтобы решать бизнес задачи, а не учить инструменты. И завтра новый чел, должен вникнуть в твою кодовую базу и снова приносить value для компании. И вроде как низкий порог вхождения === экономия для бизнеса === однозначно плюс
@@it-sin9k Только вот, есть одно но. Низкий порог вхождения, чаще всего, равен низкой профессиональности. Программист с высокими проф навыками приносит больший Value, и его код не превратится во время поддержки в x10 по деньгам для бизнеса
@@it-sin9kэто база. Почему-то многие погроммисты забывают, что их задача код писать, который будет зарабатывать деньги. И желательно, чтоб другие макаки этот код понимали, от мала до велика.
мы то знаем что лучшей стейт менеджер это $mol))))
... на палочке
Больше понравился reatom.
Но zustand конечно ментально проще.
Ну и плюс у zustand тянется схожая пачка минусов с селектора и и прочей ерундой
Цуштанд. Словцо немецкое = "состояние".
Genau
Блин) кто же знал)
@@it-sin9k Откровенно удивлен, что ты не проверил. Как теперь ролик смотреть? ))
Блин, ты мне всю жизнь испоганил ! Как жить-то теперь, когда это узнал ?! 😄
Я недавно собеседовался в нидерландскую компанию. Они говорят зустанд, не переживай)
Zustand - Цуштанд
MobX - Мобэкс
React - Риэкт
Angular - Энгюлр
Vue - Вью
Mazda - Мацуда
BMW - Биэмви
Xerox - Зирокс
Zаnussi - Дзанусси
Не благодарите😊
хтмл, жс, цсс
@@vanivka И все таки риАкт чаще) И би-эм-даблью