Видео

У меня был опыт с Zustand для SPA приложения. Крайне положительный опыт: нулевой порог вхождения, легковесный, никакого бойлерплейта

Удалил со своего проекта СтриктМод, а потом подумал, и удалил весь реакт из проекта. Потому что да, вот поэтому, все как мы любим, гениальные идеи типа а давайте в деве будет не так, как на продакшене. А давайте еще цвета будут другими, и шрифты? А то люди не следят за контрастами и аксессебилити, почему нет? А заодно и писать на деве давайте на другом языке, а потом переписывать в продашен. Ах да, и на другой платформе, давайте в деве на другой платформе писать. А на продакшене -- тоже в другой. Вот и удалил, хорошая же идея.

Прикольно, но про ref я бы упомянул бы еще тот факт, что мало того, что ref можно пропом передавать просто, так еще и HOC forward не нужен

Интересно получилось бы сложному проекту на редакс сага перейти на Zustand + react query?

пользовалась forwardRef чтобы прокинуть что-то в какой-то компонент MUI.. в формы что ли.. да, память как у рыбки, простите.

Спасибо за работу

Удивительно как до реакт коммьюнити долго доходит, что они делают какую-то чушню

effector же

Ю-туп туториалы прошли полный круг - сначала учат людей как не надо делать - использовать асинхронные вызовы прямо из компонентов, а затем как костылять эту херню, которой они научили.

Zustand очень плохо работает с Next. У них есть инструкция как его к нему подключать, но там просто жуткая простыня для каждого стора, который нужно создать. По сути если я использую Next то вся эта элегантность превращается в мрак с `useContext` и провайдорами. Идея интересная. Мне нравится, что он такой легкий и для классического SPA он хорош. Но вот ни с Astro ни с Next он к сожалению не умеет

Правильно "цуштанд"

rtk он не обгонит скорей всего, если он не станет ztk xD

ща бы в 2024 сравнивать килобайтики либ

ЦУШТАНД, ну епана

сравнивать RTK и Zustand по килобайтам.... ну такое... такое...

А какие щас бест практис, чтобы делать HTTP запросы?

Крутое видео

Почему-то, при сравнении какого-нибудь стейт-менеджера с Redux, подразумевается самый первый вариант его использования из 2015. А если ещё убрать асинхронные экшены, как предлагается в видео, то отличий будет совсем немного.)

О, это Вы еще значит не знаете про Valtio :-) вот эта мне реально понравилась. Особенно то что оно работает как для React'а, так и для Vanilla. Т.е. я могу снаружи изменить стейт и компонент перерисуется, плюс я гонял его на SSR и на клиенте, прекрасно работает.

После видео я пошел изучать зустанд через доку, уже зная редакс/тулкит. Выучил за 3 часа все что нужно, спасибо за мотивацию ❤

"Для меня Zustand стал стейт менеджером номер 1" "Я ни разу не использовал его в продакшене" Синяк наваливает базу

❤

А потом вдруг… приложение сложнее чем привет мир.. и оказывается что есть проблемы с оптимизацией:/

Слава богу)) я думал ты уже в инсту перешел😊

У меня к zustand лишь одна претензия - ооочень сильная завязка на react. Использование сторов вне компонентов неудобное, из-за чего есть проблема с вынесением бизнес логики в отдельные сервисы. Приходится все равно все закручивать вокруг react компонентов, из-за чего ui и логика очень тесно связываются Мне было бы интересно посмотреть на упомянутый в видео способ работы с асинхронными action-ами, очень жду!:)

в моем банке добавляли зустанд, сделали много ошибок при работе с ним. Полный запрет на асинхронный код - вот тут верно, мы не вовремя это поняли и многие куски кода пришлось перепиливать, *persist добавлял на пару страниц, но я не совсем успел попробовать на более сложных вещах (увольнялся из-за маленькой зп). В целом зустан заслуживает первое место в проектах. Щас работаю в другом проекте и использую редакс и честно скажу - зустан не победит редакс! у него другая архитектура и подход к проектам, что заменить редакс на зустанд будет ой как не просто

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

Как из ничего сделать видос на 8 минут))) спасибо, что почитал доку за меня

Создатель либы японец Диши Като произносит зустанд как Зустанд, так что все норм) не слушай всяких цуштандов )

Не любитель флюксов, но если выбирать между ними то zustand показался самым простым для использования на первый, поверхностный взгляд. Популярность мне кажется именно этим и обоснована. Но простое для вхождения не значит лучшее, особенно если в проекте есть хоть какая-то сложность. Пока присматриваюсь к mobx. Redux люто ненавижу

in addition to persist: you can store your values as url search/hash params and control store hidration

also I love this: useCallback(() => { const count = useStore().getState().count; }, []). And no need to have count in dependencies. Also .getState() allow you to use your state value outside components, for example in some helper functions

спасибо за познавательный видос!

После MobX Zustand не зашёл вообще. Очень многословен и нет нормальных компьютедов. Кажется, что когда (и если) в JS дотащат сигналы, такой подход будет более распространён.

ЦуштАнд…

Зустанд уже опередил редакс тулкит по скачиваниям в нпм

Не понял, почему он на хайпе? чем лучше мобх? Мобх кеширует компоненты , синтаксис использования удобный, кому надо есть автораны и прочие фишки . А в цуштанде что есть ?

Больше понравился reatom. Но zustand конечно ментально проще. Ну и плюс у zustand тянется схожая пачка минусов с селектора и и прочей ерундой

Цуштанд очень хорош, но мы используем preact-signals.

произносится как зуштанд

Немного смущает размазывание логики на множество независимых сторов. Не будет ли тяжело прокидывать preloadedState по множеству независимых сторов? Как реализовать взаимодействие/общение между этими сторами?

Надо по-немецки произносить "Цуштанд". Так круче ;) Zustand переводится с немецкого как "состояние"

мы то знаем что лучшей стейт менеджер это $mol))))

zustand прост и асинхронен. Можно передавать кастомную ф-цию сравнения изменений. Но, как комбайнить, если много функционала в связанной фиче? Slices Pattern в доках не открывается

Болею за zustand, хоть в вакансиях его и не встречал (рб), не знаю даже, почему многие до сих пор сидят на redux, а еще и thunk и тд. и тп., а еще пишут "нет легаси", ну ну :), просто нет желания переписывать, вот и тянут. Bear is here!

как заходит дело дальше примеров для инкремента счетчика, так сразу начинается обмазывание колбэками и прочей лабудой... жаль. "неочевидных прокси оберток" - странно слышать от автора, который вроде как по js же контент пилит. даже интересно, что неочевидно в Proxy? "низкий порог вхождение" - это уже должно звучать как минус. Потом такие проекты после отряда джунов нереально поддерживать. "мобикс можно написать 10 способами" = "чтобы уметь пользоваться мобикс, надо книжки читать" = "высокий порог вхождение" - так то это плюс, код всяко лучше будет выглядеть, чем написанный теми, кому хватило примеров инкремента счетчиков. за контент спасибо!

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

Не ради холивара: в Redux есть важная фича - экшены. Если мне нужно по одному экшену в разных сторах, например нужно изменение состояния в модулях, при изменении данных в глобальном состоянии (и даже может быть наоборот, чего только бизнес не попросит), то я просто импортирую экшен, который уже передает пропсы нужные и вот я уже в зависимости от них строю логику. На долгом пути такой кейс ой как оказался полезен. В Mobx же для такого кейса придется связывать отдельные сторы посредством прослоек из хуков, либо изменять один стор внутри другого стора, ну или в самом компоненте, тут каждый сам себе художник (нет). Вот интересно как связать несколько сторов в Zustand путем написания одного экшена, при этом не исключая возможности использовать этот экшен в будущем и для других сторов уровнем выше\ниже или соседние, как это имеет Redux со своими сложными редукторами -_-

Верю, что победит