Не разобраны мидлвары редакса (+ у RTK еще есть энхэнсеры). За счет централизации, мидлвары дают огромные возможности управления и позволяют строить цепочки зависимых эвентов. Например, когда отправляются 3 запроса с небольшим промежутком (например поиск при наборе текста), и каждый последующий запрос отменяет предыдущий начатый, чтоб небыло "гонки" запросов. В Зустанде этот кейс освещен небыл. Логирование/отладка не надежная из за обязательных параметров в set, что сводит доверие к ней в ноль, а доверие к инструменту отладки - критично-важная штука. Не освещена проблема типизации TS. У RTK в продакшене - это настоящая боль, если делать все правильно... либо any везде и на кой тогда TS нужен - не понятно
Подскажи ещё кейсы с использованием мидлваров в редаксе? Мне для расширения кругозора если что, а не докопаться) Просто гонку запросов при поиске решаю простым кастомным хуком (в реакте, но думаю речь итак о нем) с таймером. По поводу типов, у нас используется генератор методов с типами по опенапи схеме, потрясающая вещь) Ни без подводных, но однозначно спасение, вручную столько типов писать (и главное поддерживать) с ума сойти можно...
@@vladislav.filipov Не уверен, что кейс подходит под описание "гонки запросов". Когда страница загружается, необходимо отослать запросов 5 для получения всей информации. На первом запросе фронтэнд понимает, что токен авторизации истек. Чтобы остальные 4 запроса не отослались в молоко, мы блокируем поток запросов через mutex, перезапрашиваем токен с сервера, повторно делаем 1 запрос, и анлочим поток, делая оставшиеся 4 запроса. Ситуация с моего крайнего проекта) upd: Все запросы естественно делаются через Rtk query
@@vladislav.filipov начнем с того, что вся асинхронщина в редакс - это мидлвары, даже те-же thunk'и - это мидлвара (выполняется в мидлваре), хоть и выглядит как экшен, который диспатчат. Еще есть батчеры экшенов, когда экшенов слишком много и нужно их накапливать в течении короткого промежутка времени и разом пропускать дальше, чтоб уменьшить количество ререндеров. Логгер - мидлвара. Есть мидлвары, которые связаны с history и можно прям из экшена делать редирект. Много их, но чаще нужно какие-то специфические триггеры экшенов нужны.
10:25 парень всё видео отчаянно пытается заставлять себя произносить слово Zustand на немецкий манер - зуштант, но постоянно срывается на русское произношение - зустанд, зачем себя так мучать, ахах? Если ты говориш по-немецки с немецкоговорящими, то и произноси «зуштант» (прям аж с немецким говором), но здесь ты разговариваешь по-русски с русскоговорящей аудиторией, ну так и произноси слова на русский манер, зустанд, это нормально, разговаривая по-русски говорить на русский манер, с русской интонацией. Если какой-то бренд придумали в Германии, это не значит, что его нужно произносить на немецкий манер с немецкой интонацией, ты же японские бренды не произносишь на японский манер с японской интонацией, разговаривая по-русски с русскоговорящими, ахах.
Ничего себе работа сделана Кроме видео по теме - ещё и так подробно (сам ролик) на таймкоды разбит,,,,,, Всем Адекватности мира и добра, ребята. Успехов в учёбе - тем, кто (как я ) учится.
А давайте вы возмете проект скажем на пару тройку лямов долларов, команду и запилите на вью и пинье срм систему например для банка, потом, через пару лет когда и если закончите проект и успешно запустите, снимите видео как не обосрались с вашей пиньей и вью и тогда мы все выкинем реакт в помойку и тоже пиньи будем юзать , а то балакать вебки за 5к и проекты крупные это как бы, вроде, разные весчи ))
Антон, добрый день! Спасибо за ваши информативные видео, как всегда очень приятно смотреть. Скажите, есть ли у вас опыт использования Recoil? Достаточно много шумихи вокруг этого state manager, однако я изучив документацию не понял почему он произвел такой фурор, как по мне там слишком мало функционала, не совсем очевидная структура и я бы хотел узнать ваше мнение, был ли опыт использования и тд. Заранее благодарю!
Суть видео: - почему я выбираю Zustand? - потому что не понимаю и не умею готовить Redux-Toolkit )) 1. Бойлерплэйт код - во-первых контрится AI ассистентом или шаблонами кода. И если смотреть непредвзято, то в Redux-Toolkit его сильно не больше, просто он более явный. А в Zustand он скрытый. Например чтобы devtools подключить в каждом сторе надо его добавлять. Чтобы обработать состояния асинхронного запроса и ошибки в Zustand придется нагородить еще больше бойлерплэйта, чем в RTK для той же задачи 2. В Redux есть общий стор: это огромное преимущество, а не недостаток. С одной стороны можно разбить стор на логические фрагменты - слайсы, а с другой они соединяются через корневой стор и доступны друг другу в случае какой-то сложной логики 3. В Redux-Toolkit есть пакет Reselect, который позволяет использовать комплексные селекторы с мемоизацией. Это когда возвращаемое значение вычисляется на основе данных из разных слайсов 4. В createAsyncThunk можно получить доступ к любому слайсу комплексного стора, выполнить дополнительно любые другие экшены из других слайсов до, после или параллельно с текущим и т.д. 5. В RTK immer идет из коробки, а в Zustand его надо подключать дополнительно (к слову о бойлерплэйте) В целом RTK выглядит более взрослым решением, которое подойдет как для простых стэйтов так и для очень сложных. Но на счетчиках Zustand конечно выигрывает, вопросов нет ))
Ну во-первых, а в чем вопрос вообще? Сначала надо ответить на вопрос: "Зачем мне стейт-менкджер? Какие задачи он поможет мне решить лучше, чем встроенный useState"
Спасибо, было полезно! Антон, сделай пожалуйста обзор effector, возможно ты в следующем видео будешь говорить почему ты решил использовать effector вместо zustand 😁
Здравствуйте. Многие рекомендуют использовать zustand с react-query для запросов API. Можете подсказать, насколько это рабочая связка? И показать пример, как это должно вместе работать. Я имею в виду через хук useQuery и useMutation. Или достаточно будет обращаться к серверу способом, который вы показали?
Дружище, спасибо огромное, помог немного проще понять Redux Toolkit😂😂😂 У других не понятно, а тут каак понял, потому что другие заумно его как-то показывают. А во вторых - спасибо в целом за сравнение, наверное перейду с MobX на зустанд. Ну и конечно вопросик, это ты Copilot подключил, что редактор за тебя пол кода сам пишет?
Так в RTK есть Query, который под капотом и санки пишет и экшены, а на верх только хук генерирует, в котором уже есть все необходимое, для обработки загрузки, ошибок и прочего, а в зуштанде придется это все как я понимаю ручками прописывать и в чем тогда профит? Децентрализованный стор? не понимаю в чем его преимущество.
Недавно начал новый проект и установил в него Zustand, до этого работал на проекте где бвл Redux. После месяцев работы с Redux, Zustand - это пушка! Всё просто, понятно, без всякого бойлерплейта с thunk-ами и addBuilder-ами, просто бери и пользуйся. Похоже на усовершенствованную версию React context.
Потестил, немного отличается от RTK с точки зрения рендеринга. Если у нас есть много переменных в рамках одного store в разных компонентах то для то что бы обновлять только конкретные мы должны подписаться на конкретное значение, count = useZustandState((state) => state.count), по аналогии с RTK. Но! В отличии от Redux это же нужно сделать и для экшенов. То есть const increment = ((state) => state.increment) const decrement = ((state) => state.decrement) Если этого не сделать, то даже тот компонент, в котором используются только экшены (кнопка) будет тоже перерисовываться
Немного хейта, если позволишь, по поводу произношения) Первую часть ты произносишь как бы на Английском, зу, а вторую часть на немецком штанд. Вопрос: зачему ? 😁 Ведь это немецкое слово цуштанд(состояние). Это тоже как если произносить французское vite - вайт, вместо вит. Без негатива, просто хотелось что-то написать, а тут такой повод 😁 С уважением к Антону!
От создателей кА эс эс. А вообще никогда не понимал людей которым лень разобраться с правильным произношением. Со стороны это выглядит как бабка которая кричит что ей не "нужон ынтырнет"
Лол, во ты приколист))) RTK query рассматривать не будем))) Я редакс в принципе использую только из-за RTK query, без него лучше что-то другое использовать. RTK query поддерживает кодсплиттинг (он децентрализован), я думаю можно и слайсы при желании «децентриализовать». В редаксе провайдер нужен что бы поддерживать изоморфизм, как зустанд с SSR работает? «Мало лишнего кода» лол, это помимо стора еще нужно все экшены в интерфейс добавлять, в редаксе экшены автоматом типизируются (ну почти). А асинхронные экшены вообще не нужны с RTK query. Если делать по уму, то и стор в принципе не нужен (всмысле слайсы), RTK query закрывает все потребности. Если пофиг на изоморфизм, хочется как можно меньше бойлерплейта и самый децентрализованный стор, то watch-state в помощь, там есть @watch-state/async и @watch-state/api (эта штука шарит состояние между вкладками, такой фичи вообще ни у кого нет) для асинхонщины.
Я в свое время слез с редакса на RTK из за immutablejs, а RTK query так и не раскурил, ИМХО это большой оверхед. Децентрализованым RTK вроде сделать можно, и даже слайсы на лету добавлять-удалять (в редаксе я так делал), но только если нет мидлвар с собственным состоянием (saga - самый яркий пример). А т.к. без мидлвар оно никогда не применяется - не выйдет ((
я примерно понял вас, но на практике не представляю не подскажите где можно на код такой посмотреть. я только постигаю в rtk. с чистым редакс не работал
@@rustamakhmetyanov4404 Я искренне рекоммендую сделать хотя бы один проект на чистом редаксе для понимания внутрянки, тогда RTK будет сильно понятней. Только без TS, а то у редакса с ним не сложно, но гемора дико много, чтоб все сделать "правильно"
тема раскрыта не до конца как по мне, как обрабатывать состояния panding, fulfilled, как отлавливать ошибки на эндпоинтах. с RTK так же можно сделать отдельный слой в хуке где собрать все и отдать что нужно. А что там много болера позволяет очень гибко добавлять абстракции на нужных уровнях в зустанде это все приходится описывать в fetch функциях полагаю. Пока явного превосходства не видно как по мне
если на проекте появляется апи больше чем один запрос, то тулкит + ртк (квери) выглядит перспективней, так как в 2023 году самому писать фетчер и состояния ошибки в Стейт очень лень.
можешь объяснить пожалуйста в чем преимущество? Что в одном что в другом случае ты кэшируешь данные, только useQuery дает из коробки много фишек для работы с ним.
TanStack Query для получения данных из вне(управление асинхронным состоянием). Zustand для управления локального состояния (например фильтрация), его значение можно использовать в качестве параметра в TanStack Query.
И в чем смысл видео? Почему выбор в пользу зустанда? посмотрел всё видео и редакс выглядит лучше, при том что это простой пример + ко всему автор не добавил типизацию и селекторы, и говорит что стору нужно давать тип Выбрали зустанд потому что меньше строчек кода? а то что в проектах по больше примера, зустанд в свалку превращается не сказал. В итоге вкусовщина
Видео полезное, спасибо, но есть вопрос - а что делать, если в проекте используется zustand и модульная архитектура, где у каждого компонента свой децентрализованный стор, НО внезапно в каком-то одном компоненте понадобилось значение из другого? То есть в redux это делается легко через useSelector, ведь стейт централизован, а как сделать такое же поведение в zustand или как вообще в такой ситуации быть?
Анти паттерн. Не надо такого допускать. ИМХО. Поэтому не использую глобальные стейт-менеджеры. Зачем для каждого компонента отдельный стор на zustand-е, чем не устроил useState?
@@ПользовательПользователь-с8кне для каждого компонента. Никто тебя не запрещает иметь внутреннее состояние. Приведу пример drawer. Зачем импортить компонент в местах где он необходим каждый раз. У тебя могут быть много уникальных кейсов. Юзая глобальный стэйт тебе нужна только функция для взаимодействия. Все. Контекст не поможет потому что ты будет эффектить все компоненты и ререндерить их.
@@proletarian почему у вью один основной стейт менеджер (был vuex, для composition стал pinia), который прекрасно подходит, а у реакта их 200? опустим то, что некоторые из них можно юзать и с вью тоже (хз зачем)
Ни ssr, ни нормальных тестов (рассказ про мокинг в доке это полный треш), даже в компьютеды не умеет эта поделка - одним словом зустанд. Шляпа, распиаренная в твиттере, которая может только автоматически хук генерить. Ну и как же get/set, лучшее апи на свете. В нем просто ничего нет от слова совсем))) Спрашивается - зачем его брать на фоне существования других стм?
@@PurpleSchool Я хочу на сервере нафетчить данные, засунуть их в сторы, отрендерить страницу, зашить сериализованные данные сторов в верстку, отправить верстку на клиент, десериализовать и положить их в сторы как мне это сделать с зустандом?
@@PurpleSchool SSR и Next... Вот она, настоящая причина. Ежики продолжали колоться и кушать кактусы. Жаль, надо было сделать упор на это в видео, сравнили бы как оно летает с SSR там и здесь.
@@PurpleSchool хм, ну я считаю, что это не верный вывод. Это одна зависимость и я не понимаю, почему нужно игнорировать часть её возможностей. Вы оцениваете плюсы и минусы, так, на мой взгляд это плюс, который говорит в пользу редакс. У zustand, как я понял, нет такого функционала, даже близко. Так в чем преимущественно его перед редаксом? Что при инициализации нужно писать один раз меньше кода? А потом ещё нужно будет устанавливать другие зависимости, что бы делать запросы на сервер по человечески? Ну честно говоря, всё это говорит о преимуществах как раз редакса. Лично я, уж как-нибудь переживу, что один раз нужно будет написать немного больше кода.
@@knowledgedose1956 ну скорей всего вы и правы, но я бы хотел пояснить, представьте себе, что мы сравниваем две машины. Одна крутая, быстрая, а вторая не такая крутая и не такая быстрая, но она еще и летать умеет. И автор предлагает не принимать во внимание, что машина умеет летать, а делает выводы, что машина стремная, потому что она медленной чем другие. Но она нифига не стремная, она же ещё летает. Может она летает не так круто как самолёт, но другие машины вообще не умеют летать. Не знаю, может сложный пример я выбрал)))))
О нет, это же очередной убийца Редакса xD На самом деле было бы очень интересно узнать как он себя поведёт на +- крупном проекте когда сторов будет не один десяток. Имхо - есть какая то точка невозврата, когда рулить этим всем станет сильно сложнее чем пресловутым бойлер плейтом редакса) Не спорю, что если пишется приложение с парой-тройкой страниц, то такой стейт менеджер будет закрывать все потребности, а редакс окажется избыточным
Так Цуштанд как раз таки для крупных проектов и подходит лучше всего. То что редакс весит больше - наверное единственное, что придаёт ему "серьёзности"
@@dimenuendoну за год мое мнение не сильно поменялось) Я ради экспериментов пробовал цуштанд и мобикс использовать на проектах, да, у них есть свои интересные механизмы, но я использую ещё ртк квери, и пока таких же удобных аналогов я не нашел для себя
🔗 Ссылки:
Zustand: zustand-demo.pmnd.rs/
Redux Toolkit: redux-toolkit.js.org
🎓 Курс по React и Redux Toolkit: purpleschool.ru/course/react-...
🎓 Профессия Frontend: purpleschool.ru/profession/fr...
💬 Telegram канал с полезными советами:
t.me/purple_code_channel
Не разобраны мидлвары редакса (+ у RTK еще есть энхэнсеры). За счет централизации, мидлвары дают огромные возможности управления и позволяют строить цепочки зависимых эвентов. Например, когда отправляются 3 запроса с небольшим промежутком (например поиск при наборе текста), и каждый последующий запрос отменяет предыдущий начатый, чтоб небыло "гонки" запросов. В Зустанде этот кейс освещен небыл.
Логирование/отладка не надежная из за обязательных параметров в set, что сводит доверие к ней в ноль, а доверие к инструменту отладки - критично-важная штука.
Не освещена проблема типизации TS. У RTK в продакшене - это настоящая боль, если делать все правильно... либо any везде и на кой тогда TS нужен - не понятно
Спасибо за дополнение. В видео сложно охватить все аспекты
ну кстати спотыкался и на зу с этим. оч скудная дока по тс если не туду делать
Подскажи ещё кейсы с использованием мидлваров в редаксе? Мне для расширения кругозора если что, а не докопаться) Просто гонку запросов при поиске решаю простым кастомным хуком (в реакте, но думаю речь итак о нем) с таймером.
По поводу типов, у нас используется генератор методов с типами по опенапи схеме, потрясающая вещь) Ни без подводных, но однозначно спасение, вручную столько типов писать (и главное поддерживать) с ума сойти можно...
@@vladislav.filipov Не уверен, что кейс подходит под описание "гонки запросов". Когда страница загружается, необходимо отослать запросов 5 для получения всей информации. На первом запросе фронтэнд понимает, что токен авторизации истек. Чтобы остальные 4 запроса не отослались в молоко, мы блокируем поток запросов через mutex, перезапрашиваем токен с сервера, повторно делаем 1 запрос, и анлочим поток, делая оставшиеся 4 запроса. Ситуация с моего крайнего проекта)
upd:
Все запросы естественно делаются через Rtk query
@@vladislav.filipov начнем с того, что вся асинхронщина в редакс - это мидлвары, даже те-же thunk'и - это мидлвара (выполняется в мидлваре), хоть и выглядит как экшен, который диспатчат. Еще есть батчеры экшенов, когда экшенов слишком много и нужно их накапливать в течении короткого промежутка времени и разом пропускать дальше, чтоб уменьшить количество ререндеров. Логгер - мидлвара. Есть мидлвары, которые связаны с history и можно прям из экшена делать редирект. Много их, но чаще нужно какие-то специфические триггеры экшенов нужны.
10:25 парень всё видео отчаянно пытается заставлять себя произносить слово Zustand на немецкий манер - зуштант, но постоянно срывается на русское произношение - зустанд, зачем себя так мучать, ахах? Если ты говориш по-немецки с немецкоговорящими, то и произноси «зуштант» (прям аж с немецким говором), но здесь ты разговариваешь по-русски с русскоговорящей аудиторией, ну так и произноси слова на русский манер, зустанд, это нормально, разговаривая по-русски говорить на русский манер, с русской интонацией. Если какой-то бренд придумали в Германии, это не значит, что его нужно произносить на немецкий манер с немецкой интонацией, ты же японские бренды не произносишь на японский манер с японской интонацией, разговаривая по-русски с русскоговорящими, ахах.
Ну бутерброт как то выучили и рюкзак. И цуштанд тоже несложно.
Произносится Цуштанд. Это немецкое слово , переводится как «состояние». А видео крутое)
Спасибо
добавлю, произносится "вит" а не "вайт", это прям в доке указано, французское слово
Ничего себе работа сделана
Кроме видео по теме - ещё и так подробно (сам ролик) на таймкоды разбит,,,,,,
Всем Адекватности мира и добра, ребята.
Успехов в учёбе - тем, кто (как я ) учится.
Рад, что понравилось)
@@PurpleSchool
я сам знаю, что такое тяжёлый труд.
Поэтому всегда уважаю труд других!
Давайте теперь сравнение с Pinia, чтобы любители редукса офигели от магии.
А давайте вы возмете проект скажем на пару тройку лямов долларов, команду и запилите на вью и пинье срм систему например для банка, потом, через пару лет когда и если закончите проект и успешно запустите, снимите видео как не обосрались с вашей пиньей и вью и тогда мы все выкинем реакт в помойку и тоже пиньи будем юзать , а то балакать вебки за 5к и проекты крупные это как бы, вроде, разные весчи ))
Ну zustand на самом деле близок к ананасу. Ну конечно да, на хватает вычисляемых свойств, но все же их по идее тоже можно делать
@@sharkman6434 а давайте не натягивать сову на глобус. На видео показывают каунтер из доки, и выглядит этот каунтер раз в 10 лучше на Pinia.
@@sharkman6434 гитлаб на сколько лямов потянет ? Или озон ?
@@sharkman6434а в чем проблема Vue для разработки больших и сложных проектов? Несколько раз слышал об этом, но никаких пруфов не видел.
Антон, добрый день! Спасибо за ваши информативные видео, как всегда очень приятно смотреть. Скажите, есть ли у вас опыт использования Recoil? Достаточно много шумихи вокруг этого state manager, однако я изучив документацию не понял почему он произвел такой фурор, как по мне там слишком мало функционала, не совсем очевидная структура и я бы хотел узнать ваше мнение, был ли опыт использования и тд.
Заранее благодарю!
Спасибо! Использовал на паре проектов, похож на Zustand
Суть видео:
- почему я выбираю Zustand?
- потому что не понимаю и не умею готовить Redux-Toolkit ))
1. Бойлерплэйт код - во-первых контрится AI ассистентом или шаблонами кода. И если смотреть непредвзято, то в Redux-Toolkit его сильно не больше, просто он более явный. А в Zustand он скрытый. Например чтобы devtools подключить в каждом сторе надо его добавлять. Чтобы обработать состояния асинхронного запроса и ошибки в Zustand придется нагородить еще больше бойлерплэйта, чем в RTK для той же задачи
2. В Redux есть общий стор: это огромное преимущество, а не недостаток. С одной стороны можно разбить стор на логические фрагменты - слайсы, а с другой они соединяются через корневой стор и доступны друг другу в случае какой-то сложной логики
3. В Redux-Toolkit есть пакет Reselect, который позволяет использовать комплексные селекторы с мемоизацией. Это когда возвращаемое значение вычисляется на основе данных из разных слайсов
4. В createAsyncThunk можно получить доступ к любому слайсу комплексного стора, выполнить дополнительно любые другие экшены из других слайсов до, после или параллельно с текущим и т.д.
5. В RTK immer идет из коробки, а в Zustand его надо подключать дополнительно (к слову о бойлерплэйте)
В целом RTK выглядит более взрослым решением, которое подойдет как для простых стэйтов так и для очень сложных. Но на счетчиках Zustand конечно выигрывает, вопросов нет ))
спасибо большое за канал и школу. Вопрос : а будет ли что-то по RTK Query ?
Возможно сделаю видео
В такие моменты я люблю vue - никакого выбора, есть только pinia)) пока реакт разработчики ломают голову что лучше, vue разрабы кайфуют)
А как же VueX?) Redux для vue вроде тоже есть. да и mobx вроде существует
@@rgnaros если бы ты знал, что такое pinia, то не упоминал бы veux )))
Увы но это не так
@@rgnaros vuex это и есть тот редакс от которого все уходят постепенно, пинья мега топорная и понятная, думать не надо, просто пиши код и используй.
Ну во-первых, а в чем вопрос вообще?
Сначала надо ответить на вопрос: "Зачем мне стейт-менкджер? Какие задачи он поможет мне решить лучше, чем встроенный useState"
Спасибо, было полезно! Антон, сделай пожалуйста обзор effector, возможно ты в следующем видео будешь говорить почему ты решил использовать effector вместо zustand 😁
Гляну обязательно 😆
Здравствуйте. Многие рекомендуют использовать zustand с react-query для запросов API. Можете подсказать, насколько это рабочая связка? И показать пример, как это должно вместе работать. Я имею в виду через хук useQuery и useMutation. Или достаточно будет обращаться к серверу способом, который вы показали?
Вполне рабочий вариант, который я часто вижу на проектах
Мы начали так делать. В целом, на начальном этапе классно! Довольно простой код. Возможности есть.
Дружище, спасибо огромное, помог немного проще понять Redux Toolkit😂😂😂
У других не понятно, а тут каак понял, потому что другие заумно его как-то показывают.
А во вторых - спасибо в целом за сравнение, наверное перейду с MobX на зустанд.
Ну и конечно вопросик, это ты Copilot подключил, что редактор за тебя пол кода сам пишет?
Спасибо! Это плагин Codium
@@PurpleSchool а есть на VScode? А то у меня ни NvChad, ни Astrovim не ворк
@@code_horizon_school думаю, что есть
Так в RTK есть Query, который под капотом и санки пишет и экшены, а на верх только хук генерирует, в котором уже есть все необходимое, для обработки загрузки, ошибок и прочего, а в зуштанде придется это все как я понимаю ручками прописывать и в чем тогда профит? Децентрализованный стор? не понимаю в чем его преимущество.
Недавно начал новый проект и установил в него Zustand, до этого работал на проекте где бвл Redux. После месяцев работы с Redux, Zustand - это пушка! Всё просто, понятно, без всякого бойлерплейта с thunk-ами и addBuilder-ами, просто бери и пользуйся. Похоже на усовершенствованную версию React context.
@@WinchesterD 👍
Потестил, немного отличается от RTK с точки зрения рендеринга. Если у нас есть много переменных в рамках одного store в разных компонентах то для то что бы обновлять только конкретные мы должны подписаться на конкретное значение,
count = useZustandState((state) => state.count), по аналогии с RTK. Но! В отличии от Redux это же нужно сделать и для экшенов. То есть
const increment = ((state) => state.increment)
const decrement = ((state) => state.decrement)
Если этого не сделать, то даже тот компонент, в котором используются только экшены (кнопка) будет тоже перерисовываться
Немного хейта, если позволишь, по поводу произношения)
Первую часть ты произносишь как бы на Английском, зу, а вторую часть на немецком штанд.
Вопрос: зачему ? 😁
Ведь это немецкое слово цуштанд(состояние).
Это тоже как если произносить французское vite - вайт, вместо вит.
Без негатива, просто хотелось что-то написать, а тут такой повод 😁
С уважением к Антону!
Как и сказал в видео, так произношу)
Ааа, вот почему так странно звучит в видео.
Это на самом деле цуштанд))
От создателей кА эс эс. А вообще никогда не понимал людей которым лень разобраться с правильным произношением. Со стороны это выглядит как бабка которая кричит что ей не "нужон ынтырнет"
Лол, во ты приколист))) RTK query рассматривать не будем))) Я редакс в принципе использую только из-за RTK query, без него лучше что-то другое использовать. RTK query поддерживает кодсплиттинг (он децентрализован), я думаю можно и слайсы при желании «децентриализовать». В редаксе провайдер нужен что бы поддерживать изоморфизм, как зустанд с SSR работает? «Мало лишнего кода» лол, это помимо стора еще нужно все экшены в интерфейс добавлять, в редаксе экшены автоматом типизируются (ну почти). А асинхронные экшены вообще не нужны с RTK query. Если делать по уму, то и стор в принципе не нужен (всмысле слайсы), RTK query закрывает все потребности.
Если пофиг на изоморфизм, хочется как можно меньше бойлерплейта и самый децентрализованный стор, то watch-state в помощь, там есть @watch-state/async и @watch-state/api (эта штука шарит состояние между вкладками, такой фичи вообще ни у кого нет) для асинхонщины.
Поддерживаю данного оратора не токмо лайком, но и данным комментом.
Я в свое время слез с редакса на RTK из за immutablejs, а RTK query так и не раскурил, ИМХО это большой оверхед.
Децентрализованым RTK вроде сделать можно, и даже слайсы на лету добавлять-удалять (в редаксе я так делал), но только если нет мидлвар с собственным состоянием (saga - самый яркий пример). А т.к. без мидлвар оно никогда не применяется - не выйдет ((
А если сравнить RTK Query и Tantask React Query? Какой вывод?
я примерно понял вас, но на практике не представляю не подскажите где можно на код такой посмотреть. я только постигаю в rtk. с чистым редакс не работал
@@rustamakhmetyanov4404 Я искренне рекоммендую сделать хотя бы один проект на чистом редаксе для понимания внутрянки, тогда RTK будет сильно понятней. Только без TS, а то у редакса с ним не сложно, но гемора дико много, чтоб все сделать "правильно"
Интересненько
Спасибо
А как у Zustand дела с гидрацией при использовании с Next.js?
@@lex_nel3097 ну он в основном используется для состояния на клиенте, но гидротируется нормально
тема раскрыта не до конца как по мне, как обрабатывать состояния panding, fulfilled, как отлавливать ошибки на эндпоинтах. с RTK так же можно сделать отдельный слой в хуке где собрать все и отдать что нужно. А что там много болера позволяет очень гибко добавлять абстракции на нужных уровнях в зустанде это все приходится описывать в fetch функциях полагаю.
Пока явного превосходства не видно как по мне
Для этого заводится состояние загрузки и ошибки в State.
@@PurpleSchoolне излишний ли это бойлерплейт код?
если на проекте появляется апи больше чем один запрос, то тулкит + ртк (квери) выглядит перспективней, так как в 2023 году самому писать фетчер и состояния ошибки в Стейт очень лень.
@@jessrabbitxtв РТК оно тоже само по себе не проставится)
@@BugaevEvgenyты случайно не про rtk query говоришь?
Хотелось бы увидеть видео про Reatom, а то есть видео только от создателя. Интересен взгляд со стороны
Возможно посмотрю)
Какую нейросеть вы используете для работы с кодом ?
Codeium
Zustand для управления локального стейта подходит в связке c TanStack Query - идеально
можешь объяснить пожалуйста в чем преимущество? Что в одном что в другом случае ты кэшируешь данные, только useQuery дает из коробки много фишек для работы с ним.
TanStack Query для получения данных из вне(управление асинхронным состоянием). Zustand для управления локального состояния (например фильтрация), его значение можно использовать в качестве параметра в TanStack Query.
И в чем смысл видео? Почему выбор в пользу зустанда? посмотрел всё видео и редакс выглядит лучше, при том что это простой пример + ко всему автор не добавил типизацию и селекторы, и говорит что стору нужно давать тип
Выбрали зустанд потому что меньше строчек кода? а то что в проектах по больше примера, зустанд в свалку превращается не сказал. В итоге вкусовщина
Видео полезное, спасибо, но есть вопрос - а что делать, если в проекте используется zustand и модульная архитектура, где у каждого компонента свой децентрализованный стор, НО внезапно в каком-то одном компоненте понадобилось значение из другого? То есть в redux это делается легко через useSelector, ведь стейт централизован, а как сделать такое же поведение в zustand или как вообще в такой ситуации быть?
Ты можешь его получить: github.com/pmndrs/zustand/discussions/630
Анти паттерн. Не надо такого допускать. ИМХО.
Поэтому не использую глобальные стейт-менеджеры. Зачем для каждого компонента отдельный стор на zustand-е, чем не устроил useState?
@@ПользовательПользователь-с8кне для каждого компонента. Никто тебя не запрещает иметь внутреннее состояние.
Приведу пример drawer. Зачем импортить компонент в местах где он необходим каждый раз. У тебя могут быть много уникальных кейсов. Юзая глобальный стэйт тебе нужна только функция для взаимодействия. Все. Контекст не поможет потому что ты будет эффектить все компоненты и ререндерить их.
Почему децентрализованный стор это преимущество?
Было бы интресно посмотреть про preact-signals
Может сделаю видео
Когда он появился, я его тут же затащил на проект (Next). Но увы. Он сломал HMR, и пришлось отказаться от него в пользу Valtio
Было бы интересно посмотреть видео про Effector, а может даже и про его экосистему. Мало роликов на ютубе по данной технологии
Может быть сделаю
Почему существует 100500 стейт менеджеров?
@@jessrabbitxt потому что каждый знает как лучше
@@jessrabbitxt к примеру тащить RTK в какой то маленький проект как то не целесообразно
@@proletarian почему у вью один основной стейт менеджер (был vuex, для composition стал pinia), который прекрасно подходит, а у реакта их 200? опустим то, что некоторые из них можно юзать и с вью тоже (хз зачем)
Воу воу воу на холивар нарываетесь молодой человек
Ну не очень я уже и молодой...
Подскажите люди добрые как реализовать такие подсказки продолжения кода в VS Code ?
скорее всего, это Capilot, он уже платный стал
Это Codium и он бесплатен
или Codeium@@PurpleSchool Потому что Codium я поставил вроде как бесплатно только временно далее просит купить подписку
@@dencheechoo3681 👍
блин цуштант звучит ужасно - хоть и типо правильно, как на немецком... зустанд - звучит круче
Этот Жуштенд ужасен, please так же подробно effector, он бомба!
Это ещё бл что такое??? Опять что-то нужно учить?! Да ёмаёё....
Ха-ха-ха)
По-немецки цуштанд это состояние. Возможно так и следует его называть
Мне уже физически больно смотреть на код написанный на redux, это же просто невыносимо переусложненная машина для решения тривиальных задач.
Есть такое
О, теперь экшены именнованные в девтулс для Зустанда?
Их можно назвать, да
Учу немецкий, и потому зуштанд делает больно моим ушам😅
Z это "цэт" )
😅
А что думаете насчёт effector?
Не пробовал на проде
Mobx one love
Ни ssr, ни нормальных тестов (рассказ про мокинг в доке это полный треш), даже в компьютеды не умеет эта поделка - одним словом зустанд. Шляпа, распиаренная в твиттере, которая может только автоматически хук генерить. Ну и как же get/set, лучшее апи на свете. В нем просто ничего нет от слова совсем)))
Спрашивается - зачем его брать на фоне существования других стм?
Zustand отлично работает с SSR и Next.
@@PurpleSchool
Я хочу на сервере нафетчить данные, засунуть их в сторы, отрендерить страницу, зашить сериализованные данные сторов в верстку, отправить верстку на клиент, десериализовать и положить их в сторы
как мне это сделать с зустандом?
@@PurpleSchool SSR и Next... Вот она, настоящая причина. Ежики продолжали колоться и кушать кактусы. Жаль, надо было сделать упор на это в видео, сравнили бы как оно летает с SSR там и здесь.
Наш вариант pinia❤
Не совсем понял, почему автор не рассматривает RTK-QUERY? Он вроде как из коробки идет, ничего дополнительного не нужно устанавливать.
Отдельно по нему сделаю разбор. Просто его правильно сравнивать с React Query.
@@PurpleSchool хм, ну я считаю, что это не верный вывод. Это одна зависимость и я не понимаю, почему нужно игнорировать часть её возможностей. Вы оцениваете плюсы и минусы, так, на мой взгляд это плюс, который говорит в пользу редакс. У zustand, как я понял, нет такого функционала, даже близко. Так в чем преимущественно его перед редаксом? Что при инициализации нужно писать один раз меньше кода? А потом ещё нужно будет устанавливать другие зависимости, что бы делать запросы на сервер по человечески? Ну честно говоря, всё это говорит о преимуществах как раз редакса. Лично я, уж как-нибудь переживу, что один раз нужно будет написать немного больше кода.
@@01slonя бы сказал что react query удобней rtk query, и да это отдельная зависимость, ничего страшного в этом нет
@@knowledgedose1956 ну скорей всего вы и правы, но я бы хотел пояснить, представьте себе, что мы сравниваем две машины. Одна крутая, быстрая, а вторая не такая крутая и не такая быстрая, но она еще и летать умеет. И автор предлагает не принимать во внимание, что машина умеет летать, а делает выводы, что машина стремная, потому что она медленной чем другие. Но она нифига не стремная, она же ещё летает. Может она летает не так круто как самолёт, но другие машины вообще не умеют летать. Не знаю, может сложный пример я выбрал)))))
@@PurpleSchool согласен!
О нет, это же очередной убийца Редакса xD
На самом деле было бы очень интересно узнать как он себя поведёт на +- крупном проекте когда сторов будет не один десяток. Имхо - есть какая то точка невозврата, когда рулить этим всем станет сильно сложнее чем пресловутым бойлер плейтом редакса) Не спорю, что если пишется приложение с парой-тройкой страниц, то такой стейт менеджер будет закрывать все потребности, а редакс окажется избыточным
так мультисторы как раз лучше мастабируются чем один огромный стор на все. Так как апдейты всегда атомарные без лишней мемоизации
Вот придумываете себе проблем
Инструментом надо уметь пользоваться. By default в 95% случаев, если не больше, вам ни redux, ни zustand не нужны
Так Цуштанд как раз таки для крупных проектов и подходит лучше всего.
То что редакс весит больше - наверное единственное, что придаёт ему "серьёзности"
@@dimenuendoну за год мое мнение не сильно поменялось)
Я ради экспериментов пробовал цуштанд и мобикс использовать на проектах, да, у них есть свои интересные механизмы, но я использую ещё ртк квери, и пока таких же удобных аналогов я не нашел для себя
Mobx и reatom самые классные, у Mobx так вообще самый чистейший код, zustand в сравнении с ним какая то поделка.
reatom top
Pls make comparison your editor vs vscode
👍
А надо было effector
Жаль не рассказал что зустанд по дефолту хранит данные в локалСторэдже)))
Нет, только если ему подключить Persist Middleware
MobX - лучший инструмент для управления состоянием. А вот на zustand и ему подобных только to-do листы писать =)
Почему?
Странно что статистика npm говорит о другом 😂
@@PurpleSchool Большие проекты обычно на RTK или MobX, на Zustand не видел
@@СамирАбасов Действительно, тысячи мух не могут ошибаться =) Это как с create-react-app, который первый по деплоям на Netlify
@@JJohnson-fy9uz так и годиков сколько ему
что за браузер на видео?
Arc Browser. У меня есть про него видео
Mobx - наше всё.
Посмотрел. Если у вас в коде компоненты фигурирует dispatch, то вы знаете об возможностях rtk примерно как большинство разработчиков про JS.
Я тоже перешел на zustand
👍
Выбирать надо эффектор
Почему?)
reatom )
Студенты чего? Zustand?
purpleschool.ru/
А ещё zustand быстрее.
Отличный разбор, но жаль, что не рассматривается способ как при сборке девтулз выкинуть)
Спасибо
цуштант)
Цуштанд. Немецкий язык.
reatom лучше
Цуштанд
Редакс это дерьмо.