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