Насчёт React-Query, было бы хорошо если ты расскажешь в каких случаях стоит его использовать с стором, потому что в основном, если не всегда на мой взгляд react-query полностью убивает всякие сторы, потому что там можно хранить данные в кеше вечно и полностью сторы теряют смысл работы с сервером. + Так же react-query умеет работать с persist.
А прикол в том, что стор кроме как хранения юзера и каких-нибудь вещей для отрисовки сложного ui не нужен. все решается с помощью react-query + конекст с локальным состоянием для каждой страницы
Хранить в кэше на фронте можно очень ограниченное количество информации, которое долго остается актульным типа данные юзера или данные о событиях, которые не могут измениться. В высоконагруженных системах возлагать контроль за актуальностью кэша на фронт будет глупо с точки зрения перфоманса и этим чаще всего занимается бэкенд(есть специальные алгоритмы поддержания кэша). Мы использовали персист на фронте для хранения токенов и каких-то ключей, уже и не вспомню
@@doichev-kostia большинство клиентских Стейт менеджеров предоставляют работу с асинхронными данными, но если выбирать между клиентским стейтом и react-query, то логичнее использовать react-query. А для клиентских данных ну тут на самом деле можно использовать обычный контекст. Зачем я буду в проект заносить лишний "вес" ради того чтобы хранить какая цветовая тема сайта стоит у пользователя? Тем более если брать пример все же с получением данных, то после обновления страницы все слетит. Насчёт комментария выше соглашусь, то что для большого проекта вместо клиентского Кеша можно вынести на сервер, но опять же тут клиентский стор и не нужен, если так же будем использовать react-query. Мы просто отключим кеширование.
@@daddyj2049 да, соглашусь, но, если честно, контекст не очень хорош, потому что после любого изменения стейта, он полностью перерендеривает всех children, что не очень прикольно. В наших SPA для любых данных с API, мы используем react-query, но иногда есть куски, где стейт нужно чисто клиентский и, честно говоря, я бы предпочёл zustand или jotai вместо react context
Цуштанд - с немецкого "состояние" или State 😀 Спасибо за видео! Отличная подача информации, и даже не играет роли произношение слов на разных языках. Главное - это знания, которыми Вы с нами делитесь 🎉
Очень странно, что на том же гитхабе нет транслитерации. Что-то вроде Zustand [ˈtsuːʃtant] - a german word for "state" А вообще, кончено забавно как это произносят остальные блогеры. "Застанд" и "зЮстЭнд" пока мои самые любимые ))) На самом деле ухо режет ппц, так как живу в Германии и с коллегами разговариваю на немецком...
Чтобы в девтулс отображались не анонимные экшены, в сторе при set в опциях можно передать строкой название какое хотите. Тогда в редакс девтулс наглядно всё видно
2 года писал на effector попробывал reatom, теперь новые проекты пишу на reatom - код намного понятнее становится, и больше функционала там чем в effector
Есть ещё один замечательный подход к сторам во фронте - это Effector. Невероятно функциональный и декларативный. Контрибуторы - те же люди, кто делал Feature-Sliced-Design. Хочется увидеть обзор на Effector. Залайкайте коммент, чтобы Ульби увидел 😄👍
@@КириллВласов-ъ4э не знаю о "модульной философии" =) Методология FSD говорит нам о том, что нефиг что попало, импортить куда попало. Взять к примеру хук о котором ты пишешь - useHook (или что угодно из директории /user/hook).При правильном использовании FSD мы не сможем зависеть от этого хука в компонентах shared слоя и это отлично! так и должно быть. В остальном, кладешь этот хук, предполагаю в entities/user/ и юзай себе спокойно как ты говоришь из любой точки
@@КириллВласов-ъ4э Это где ж в FSD такая схема? /shared/hooks/ - это да. Никаких /user/hook быть не может. И в шаред лежат только компоненты, не несущие бизнес-логики: кнопки, дропдауны, все вот это...
React Query для работы с "серверным" стейтом приложения (server state data management), Zustand - для работы с клиентским стейтом. Если клиентское приложение тонкое (минимум бизнес логики, все данные в нужном формате возвращаются с бекенда), то возможно Zustand и другие стейт менеджеры вообще будут не нужны, но если толстое, то удобно с данными работать как раз таки через Zustand
Не очень понятно из видео как работать с версионированием персиста, но это уже в документации почитаю, спасибо за ролик!) Хотелось бы увидеть видео про React Query)
Пытался освоить редакс - сложно было понимать механику, наткнулся на этот видос. Боже... Какой же цуштанд обалденный! Плюс твои пояснения, в итоге кайфую. Мои мысли касательно Цуштанда вообще: так обязан был выглядеть useState+useContext Кстати, "immer" (имма) - тоже на немецком, означает "всегда"
Отличное видео. Как всегда, никакой воды. Спасибо, что уважаешь наше время. Да, очень хотелось бы посмотреть видео об Реакт Квери т.к. хочу его выучить. Не писал на нем, но точно знаю, что на данный момент это best practice, и нужно идти в ногу со временем, не отставать от рынка. Не зря в редакс-тулкит запихнули тот же РТК
Ролик прямо как в старые-добрые:))) давно не видел те ламповые видео, с разбором какой-то локальной темы🤗 Zustand последние пол года постоянно маячит перед носом, но руки пока не дошли... Вроде крайне дружелюбный, как мишка на лого🤣
Захотелось написать Тимуру хороший комментарий, оставлю здесь, тк моя мини-стори завязана на этом ролике. Я пришел на замену человечку в проект, написанный наскоро на Svelte. Чинил оставленные баги, старался улучшить архитектуру в меру своих знаний. И так получилось, что один из багов представлял из себя ререндендеринг и рерутинг на главную страничку при любом изменении данных в сторе, даже если измененные данные не имели отношение к отображаемой сейчас страничке и никак не затрагивались. Почему так происходило я вообще не понимал и помочь мне особо никто не мог. В один из дней я пересматривал этот ролик и как раз обратил внимание про оговорку Тимура, что изменение формально не связанных данных в сторе с текущим компонентом все равно триггерит ререндеринг этого компонента. Проверил тестово на сторах Свелта и тоже увидел такое же поведение. Так что только благодаря Тимуру я смог осознать в чем состоит проблема и стал разгребать этого рейд босса) Спасибо большое
Хорош! У нас в компании это основной стейт менеджер, активно использую и в собственных проектах Для запросов у нас самописные слайсы с реакциями Жду видео о React Query
Обожаю эту либу.... Использовал в продакшене а 2 проектах на React Native. Все безумно легко и удобно настраивается (если это требуется) + все на ТС. Сейчас на проекте редакс, и это просто боль работать с ним после зустанд...
Сейчас в пет проекте как раз использую zustand и react query и скажу всем что комбинация крутая Тулкит редаксовский посощнек конечно, но для небольших проектов зустанд это пушка, очень быстро можно писать код и не делать себе мозги всякими слайсами, редюсерами или реактовскими контекстами
По моему опыту zustand, valtio можно хорошо использовать с простыми данными. Очень хорошо оптимизированы из коробки. С большими и сложными данными иногда появляются баги, которые без костылей не решить. Иногда плохо типизируется с ts. В большинстве случаев отказался от них, но есть очень редкие кейсы в которых они в разы лучше redux.
react-query обязательно обзор нужен. Причем полный и всеохватывающий. Либа очень полезная, но довольно объемная по документации. Хотчелось бы структуризированную инфу. Спасибо!
Тимур, большое спасибо! очень хочется видос про react-query, а особенно сравнение с RTK-query. вроде как React-query имеет больше фичей и интереснее, но не избыточно ли? хочется узнать твое мнение. Ребята, залайкайте пожалуйста.
мне вот интересно, а что значит - с redux'а не охота переходить никуда, все устраивает. ? я вот работаю в компании, на мне 2 проекта, оба на редаксе, ну вот понравился мне zustand, и чего? Мне, что все перепиливать с redux'а на zustand? Да я умру пока это все сделаю + технология для меня новая буду гуглить как то как сё, баги, вообщем потрачу на это не один месяц, а ведь есть и текущие таски. Конечно новый проект можно начинать но "Переходить", это как-то странно, не зрело, что-ли.
@@ylsv так я понять хочу а не затролить) что значит переходить? переписывать то, что есть? или начинать новый проект с новым стеком? Коммент в поддержку канала, разумеется.
@@ЮрийМусатов-ь3я хз, зачем это тебе, ну ок) у меня самого в продакшне 3 проекта на редаксе, один на вью, естественно не буду ничего переписывать, тем более не имея таких полномочий. в контексте коммента под переходом можно понимать, например, пет-проекты, где можно вместо редакса применить этот новый менеджер, либо людей, которые работают на фрилансе, не зависят особо от стека и могут применить новую интересную технологию. одну из сотен тысяч на фронте, которые появляются чуть ли не каждый месяц. естественно не будешь так прыгать в больших проектах постоянно)
Спасибо огромное!!! Я почему-то как один раз про mobx посмотрел видео, привык к нему, даже не смотрел на актуальность его и тем более весь, 50 кб.... Сейчас redux чутка подучу и потом на zustund можно спокойно будет переходить
Спасибо за обзор. Интересный стейт менеджер, редух уже изжил себя, а скачиваний много из-за пиара и того, что его по началу засовывали во все проекты... а сейчас мучаются))
Либо я пропустил, либо про get ничего не было сказано. И ещё про использование данных из одного стора в другом. Сама библиотека топ, доволен полностью.
Тимур, сердечно прошу записать ролик про react-query🙏. Очень хотелось бы подробное сравнение обработчиков onError и catch при работе с axios interceptors при авторизации, ну конечно же лучшие практики💥, как пример фабрикики в которых создаются объекты queryKey, queryFn для удобной вставки в сам хук. Спасибо за контент☺, ты делаешь сообщество разработчиков в РФ лучше.
От души за разбор, завтра пойду щупать, у меня в одном сайте react чисто на контексте, посмотрим что это такое ваш зустанд, подкупает что по сути никаких настроек не надо, скачал, создал функцию стор и работаешь с данными, профит Upd: Единственно что я подметил это то что не стоит мешать стэйт с диспатчем как у тебя, так стор быстро в мешанину превратиться, я обычно это дело решаю так, сам контекст (он же стор) делю на две части, собственно сам стор и диспатч в котором по ключу меняю стор, посмотрим подойдет ли такой подход здесь или придется что то новое мутить
Очень хотелось бы разбор React Query.
Насчёт React-Query, было бы хорошо если ты расскажешь в каких случаях стоит его использовать с стором, потому что в основном, если не всегда на мой взгляд react-query полностью убивает всякие сторы, потому что там можно хранить данные в кеше вечно и полностью сторы теряют смысл работы с сервером. + Так же react-query умеет работать с persist.
А прикол в том, что стор кроме как хранения юзера и каких-нибудь вещей для отрисовки сложного ui не нужен. все решается с помощью react-query + конекст с локальным состоянием для каждой страницы
Хранить в кэше на фронте можно очень ограниченное количество информации, которое долго остается актульным типа данные юзера или данные о событиях, которые не могут измениться. В высоконагруженных системах возлагать контроль за актуальностью кэша на фронт будет глупо с точки зрения перфоманса и этим чаще всего занимается бэкенд(есть специальные алгоритмы поддержания кэша). Мы использовали персист на фронте для хранения токенов и каких-то ключей, уже и не вспомню
React query - server state (данные), zustand/jotai/valtio - client state
@@doichev-kostia большинство клиентских Стейт менеджеров предоставляют работу с асинхронными данными, но если выбирать между клиентским стейтом и react-query, то логичнее использовать react-query.
А для клиентских данных ну тут на самом деле можно использовать обычный контекст. Зачем я буду в проект заносить лишний "вес" ради того чтобы хранить какая цветовая тема сайта стоит у пользователя? Тем более если брать пример все же с получением данных, то после обновления страницы все слетит.
Насчёт комментария выше соглашусь, то что для большого проекта вместо клиентского Кеша можно вынести на сервер, но опять же тут клиентский стор и не нужен, если так же будем использовать react-query. Мы просто отключим кеширование.
@@daddyj2049 да, соглашусь, но, если честно, контекст не очень хорош, потому что после любого изменения стейта, он полностью перерендеривает всех children, что не очень прикольно.
В наших SPA для любых данных с API, мы используем react-query, но иногда есть куски, где стейт нужно чисто клиентский и, честно говоря, я бы предпочёл zustand или jotai вместо react context
Цуштанд - с немецкого "состояние" или State 😀
Спасибо за видео! Отличная подача информации, и даже не играет роли произношение слов на разных языках. Главное - это знания, которыми Вы с нами делитесь 🎉
Застанд 😂
Коллегам немцам показал, очень смеялись 😂
Z нацисти😅
Очень странно, что на том же гитхабе нет транслитерации. Что-то вроде
Zustand [ˈtsuːʃtant] - a german word for "state"
А вообще, кончено забавно как это произносят остальные блогеры. "Застанд" и "зЮстЭнд" пока мои самые любимые )))
На самом деле ухо режет ппц, так как живу в Германии и с коллегами разговариваю на немецком...
Только без т на конце, просто Цуштанд :)
Я тоже так и прочитала😂когда знаешь немецкий, читать английский становится сложнее 😂
Привет. Про React query, обязательно стоит сделать ролик я считаю. О том как работать с ним в ssr вместе с каким нибудь СТМ с fsd архитектурой.
Ждемс реакт-квери, всякие приколы в нем и хорошие паттерны написание запросов.
Чтобы в девтулс отображались не анонимные экшены, в сторе при set в опциях можно передать строкой название какое хотите. Тогда в редакс девтулс наглядно всё видно
раскидал за 10 минут! Просто и понятно! Огромное спасибо за твои старания! Ждём такой же ролик по effector)
2 года писал на effector
попробывал reatom, теперь новые проекты пишу на reatom - код намного понятнее становится, и больше функционала там чем в effector
Просто для информации: это немецкое слово и читается как цуштанд👍 . Видео огонь как всегда! Спасибо 🙏🏻
Ждём про React Query, спасибо за титанические труды!
Никогда не поленюсь написать "Красава, хорош, так держать, давай еще" если я досмотрел видео до конца :)
Есть ещё один замечательный подход к сторам во фронте - это Effector. Невероятно функциональный и декларативный. Контрибуторы - те же люди, кто делал Feature-Sliced-Design. Хочется увидеть обзор на Effector. Залайкайте коммент, чтобы Ульби увидел 😄👍
Я FSD проникся и внедрил в проект. Просто пушка 🔥Не знал что эффектор их продукт. Обязательно теперь чекну и попробую. Спасибо за мысль)
плюс! использую еффектор на постоянной основе уже давно - он классный
@@enslit FSD частично нарушает философию модульной архитектуры, когда из любой точки приложения ты достаешь компонент или хук из /user/hook/...
@@КириллВласов-ъ4э не знаю о "модульной философии" =) Методология FSD говорит нам о том, что нефиг что попало, импортить куда попало.
Взять к примеру хук о котором ты пишешь - useHook (или что угодно из директории /user/hook).При правильном использовании FSD мы не сможем зависеть от этого хука в компонентах shared слоя и это отлично! так и должно быть. В остальном, кладешь этот хук, предполагаю в entities/user/ и юзай себе спокойно как ты говоришь из любой точки
@@КириллВласов-ъ4э Это где ж в FSD такая схема? /shared/hooks/ - это да. Никаких /user/hook быть не может. И в шаред лежат только компоненты, не несущие бизнес-логики: кнопки, дропдауны, все вот это...
Спасибо за классный обзор. Хотим еще по React-Query)
круто, что обозреваешь такие технологии, которые только на этапе зарождения
его уже используют в проде
это не про zustand, он уже довольно популярный
это редакс вид сбоку, чтоб было немного меньше боли, пока не открыли для себя мобкс, где ее вообще нет
Боли нет пока не пришлось дебажить)
Это знак свыше!=) Только сегодня утром искал и просматривал материалы по Zustand!=)))Спасибо за работу!
ваша мольба услышана)
зачем все эти кривые костыли и бойлерплейты когда есть мобкс, где все работает автоматом
Видео как всегда очень приятное! Да, видео по React Query было бы здорово посмотреть, спасибо
4:45 - в случае с Typescript, чтобы все работало, вызывать функцию нужно так - create( ) ( (set) => {...} )
Интересно было послушать про Zustand, хочется попробовать в деле)
Про react-query обязательно нужен ролик!
спасибо! Стало сразу понятно, что это, и какие есть преимущества
Ждём React Query, да и много ещё чего ждём. Спасибо за шикарные видео)
React Query для работы с "серверным" стейтом приложения (server state data management), Zustand - для работы с клиентским стейтом. Если клиентское приложение тонкое (минимум бизнес логики, все данные в нужном формате возвращаются с бекенда), то возможно Zustand и другие стейт менеджеры вообще будут не нужны, но если толстое, то удобно с данными работать как раз таки через Zustand
Тимур - лучший педагог!
Спасибо огромное за ролик, подача как всегда на высоте!
React Query тоже очень хотелось бы)
Не очень понятно из видео как работать с версионированием персиста, но это уже в документации почитаю, спасибо за ролик!) Хотелось бы увидеть видео про React Query)
Пытался освоить редакс - сложно было понимать механику, наткнулся на этот видос.
Боже... Какой же цуштанд обалденный!
Плюс твои пояснения, в итоге кайфую.
Мои мысли касательно Цуштанда вообще: так обязан был выглядеть useState+useContext
Кстати, "immer" (имма) - тоже на немецком, означает "всегда"
Ждем видео про React Query. И не плохо было бы уже заменить create-react-app на Vite.
Отличный ролик, краткий, лаконичный, по существу
Так держать
Поддерживаю, очень интересно будет послушать про React-query 🔥🔥🔥
Отличное видео. Как всегда, никакой воды. Спасибо, что уважаешь наше время.
Да, очень хотелось бы посмотреть видео об Реакт Квери т.к. хочу его выучить. Не писал на нем, но точно знаю, что на данный момент это best practice, и нужно идти в ногу со временем, не отставать от рынка. Не зря в редакс-тулкит запихнули тот же РТК
Спасибо, Тимур👍
Про Реакт интересно)
спасибо, Тимур! Как всегда всё кратко, понятно. Лучший)
Ролик прямо как в старые-добрые:))) давно не видел те ламповые видео, с разбором какой-то локальной темы🤗 Zustand последние пол года постоянно маячит перед носом, но руки пока не дошли... Вроде крайне дружелюбный, как мишка на лого🤣
Последнее время действительно от фронта больше к общим темам ушли, но мне это наоборот нравится
@@dontcodeэто неплохо, но изредка вот такие ролики тоже очень приятно глянуть 👍👍👍
@@ipa_stor согласен
Как всегда топ контент !
Как всегда все круто! React Query очень хочется
Мне его как раз не хаватало) Не понимал зачем один глобальный стейт нужен, когда сложное приложение)
Спасибо зза ролик!
Спасибо очень информативно! Очень сильно ощутил разницу между redux и zustand
Как хорошо, что есть Ваш канал!
Zustand react
Спасибо за видео! Подробный разбор react-query очень нужен!)
спасибо за видос. очень нравится твоя форма изложения материала. всё по делу, в хорошем темпе и все понятноё. Жду продолжения видосов про архитектуру
уже 300 к бор у тебя !) поздравляю Тимур !!!!! ты заслужил !!!
Интересно было послушать, спасибо. Попробую внедрить к себе в проект
Цу-Штанд (нем. Состояние / англ. state)
Спасибо за контент! Кто знает, может когда-нибудь дойдём и до valtio.
Забавный факт, у Valtio, Zustand и Jotai один автор
Лучшее - однозначно 👍
было бы интересно также как использовать react query и zustand вместе. спасибо за ролик!
Классный разбор Zustand. Также хотелось бы разбор и про react-query!
Цуштанд, это немецкий, переводится как состояние
Хотелось бы понять, как работать с react-query, спасибо за разбор zustand!
Захотелось написать Тимуру хороший комментарий, оставлю здесь, тк моя мини-стори завязана на этом ролике. Я пришел на замену человечку в проект, написанный наскоро на Svelte. Чинил оставленные баги, старался улучшить архитектуру в меру своих знаний. И так получилось, что один из багов представлял из себя ререндендеринг и рерутинг на главную страничку при любом изменении данных в сторе, даже если измененные данные не имели отношение к отображаемой сейчас страничке и никак не затрагивались. Почему так происходило я вообще не понимал и помочь мне особо никто не мог. В один из дней я пересматривал этот ролик и как раз обратил внимание про оговорку Тимура, что изменение формально не связанных данных в сторе с текущим компонентом все равно триггерит ререндеринг этого компонента. Проверил тестово на сторах Свелта и тоже увидел такое же поведение. Так что только благодаря Тимуру я смог осознать в чем состоит проблема и стал разгребать этого рейд босса) Спасибо большое
🔥🔥
RtQ очень нужен видос, спасибо!
Спасибо большое за обзор. Как всегда кратко и содержательно. Хороший стейт менеджер, но если брать мульттстор, то ИМХО эффектор вне конкуренции.
коммент в поддержку канала Тимура и выпуска видео по React Query😊
Коммент в поддержку !
Хорош!
У нас в компании это основной стейт менеджер, активно использую и в собственных проектах
Для запросов у нас самописные слайсы с реакциями
Жду видео о React Query
Спасибо за видео! Интересный формат, продолжай.
Ждем React Query!
Обожаю эту либу.... Использовал в продакшене а 2 проектах на React Native. Все безумно легко и удобно настраивается (если это требуется) + все на ТС. Сейчас на проекте редакс, и это просто боль работать с ним после зустанд...
мобкс на порядок удобнее и проще обоих
@@xDiezz правда напрягает то, что компоненты которые должны подписываться на изменения в сторе, должны быть обернуты в observer
Обязательно mobx попробуйте, больше на велосипеды костыльные на подобие редакса смотреть даже не будете
Сейчас в пет проекте как раз использую zustand и react query и скажу всем что комбинация крутая
Тулкит редаксовский посощнек конечно, но для небольших проектов зустанд это пушка, очень быстро можно писать код и не делать себе мозги всякими слайсами, редюсерами или реактовскими контекстами
Попробуйте mobx, скорость разработки и простота в разы выше
Да, очень хорошая идея, сделать обзор React-Query
по квери тоже надо видео!) спасибо за видос)
По моему опыту zustand, valtio можно хорошо использовать с простыми данными. Очень хорошо оптимизированы из коробки.
С большими и сложными данными иногда появляются баги, которые без костылей не решить. Иногда плохо типизируется с ts.
В большинстве случаев отказался от них, но есть очень редкие кейсы в которых они в разы лучше redux.
Спасибо за ролик. Пока выглядит как нативный React context только в профиль
Спасибо за крутое видео!
Спасибо большое за обзор! Было бы замечательно посмотреть твой обзор React Query!)
react-query обязательно обзор нужен. Причем полный и всеохватывающий. Либа очень полезная, но довольно объемная по документации. Хотчелось бы структуризированную инфу. Спасибо!
Чотенько, хотелось бы еще реакт квери! Спасибо, Тимуp :)
как всегда супер
Тимур, большое спасибо! очень хочется видос про react-query, а особенно сравнение с RTK-query. вроде как React-query имеет больше фичей и интереснее, но не избыточно ли? хочется узнать твое мнение. Ребята, залайкайте пожалуйста.
Интересно, смотрим!💥
О react- query было бы интересно узнать
интересный видос, спасибо. но пока с redux'а не охота переходить никуда, все устраивает) про react-query будет тоже интересно глянуть, хорошая идея
мне вот интересно, а что значит - с redux'а не охота переходить никуда, все устраивает. ? я вот работаю в компании, на мне 2 проекта, оба на редаксе, ну вот понравился мне zustand, и чего? Мне, что все перепиливать с redux'а на zustand? Да я умру пока это все сделаю + технология для меня новая буду гуглить как то как сё, баги, вообщем потрачу на это не один месяц, а ведь есть и текущие таски. Конечно новый проект можно начинать но "Переходить", это как-то странно, не зрело, что-ли.
@@ЮрийМусатов-ь3я просто написал "странный и незрелый" коммент в поддержку канала, не надо искать скрытых смыслов)
@@ylsv так я понять хочу а не затролить) что значит переходить? переписывать то, что есть? или начинать новый проект с новым стеком? Коммент в поддержку канала, разумеется.
@@ЮрийМусатов-ь3я хз, зачем это тебе, ну ок) у меня самого в продакшне 3 проекта на редаксе, один на вью, естественно не буду ничего переписывать, тем более не имея таких полномочий. в контексте коммента под переходом можно понимать, например, пет-проекты, где можно вместо редакса применить этот новый менеджер, либо людей, которые работают на фрилансе, не зависят особо от стека и могут применить новую интересную технологию. одну из сотен тысяч на фронте, которые появляются чуть ли не каждый месяц. естественно не будешь так прыгать в больших проектах постоянно)
@@ylsv чё-то ниче интересного в ролике я не нашёл, вся эта логика делается в rtk и без боли
Спасибо. Хотелось бы увидеть именно связку с React Query, как и было заявлено в названии ролика.
Кликбейтить начал чувак, сообщество не одобряет
Спасибо большое за твое хорошее дело
Спасибо за ролик)
React query теперь ждём ролик
Добрый день. Жду обзор за BlitzJS. Использую и очень радуюсь. Жизнь стала проще.
Спасибо за видео!
Нужен обзор на react query)
Прикольный стейт, но все равно предпочитаю MobX за его простоту и удобность)
Ждем все , что сейчас актуально
Спасибо огромное!!! Я почему-то как один раз про mobx посмотрел видео, привык к нему, даже не смотрел на актуальность его и тем более весь, 50 кб.... Сейчас redux чутка подучу и потом на zustund можно спокойно будет переходить
Zustand имеет много общего с Pinia используемой во VueJS.
recoil здорового человека
Спасибо! Я как раз разбирался с FSD архитектурой. Redux как то туда криво вписывается, а вот это то что нужно))
Значит плохо разобрался, все что связано со стором можно держать в сущностях в сегменте model
Спасибо за обзор. Интересный стейт менеджер, редух уже изжил себя, а скачиваний много из-за пиара и того, что его по началу засовывали во все проекты... а сейчас мучаются))
Отличное видео. И + за видео про React Query
Pinia для Vue js такой же подход использует.
Выглядит весьма!
Названия ты можешь после сета через запятую добавить, тогда в девтулзах будет видно название экшена
Либо я пропустил, либо про get ничего не было сказано. И ещё про использование данных из одного стора в другом. Сама библиотека топ, доволен полностью.
👍 Жду гайд по React-Query
Всё понятно и круто, спасибо! теперь ожидаем на очереди react query)
Было бы круто увидеть видос связанный с мультисторами редакса и модульным подходом
круто, хотелось бы мини урок про React Query с практикой, спасибо
Хочу ролик по React query. Спасибо)
выглядит интересно, тоже хотелось бы узнать используют ли его в проде
Было бы отлично, если бы ты сделал видео по React Query
Хочется ролик про ReactQuery! Спасибо за твои видео
А зачем в названии присутствует React query? Ведь он не рассматривается в ролике и в библиотеке его нет
Кто-нибудь после того как начал использовать react-query может объяснить зачем нужен клиентский стейт? Что вы там храните?
Тимур, сердечно прошу записать ролик про react-query🙏. Очень хотелось бы подробное сравнение обработчиков onError и catch при работе с axios interceptors при авторизации, ну конечно же лучшие практики💥, как пример фабрикики в которых создаются объекты queryKey, queryFn для удобной вставки в сам хук. Спасибо за контент☺, ты делаешь сообщество разработчиков в РФ лучше.
От души за разбор, завтра пойду щупать, у меня в одном сайте react чисто на контексте, посмотрим что это такое ваш зустанд, подкупает что по сути никаких настроек не надо, скачал, создал функцию стор и работаешь с данными, профит
Upd: Единственно что я подметил это то что не стоит мешать стэйт с диспатчем как у тебя, так стор быстро в мешанину превратиться, я обычно это дело решаю так, сам контекст (он же стор) делю на две части, собственно сам стор и диспатч в котором по ключу меняю стор, посмотрим подойдет ли такой подход здесь или придется что то новое мутить