🎙️ Дмитрий Бабин - Вам не нужен state менеджер (react, redux, zustand, reatom, state managment)

[@elluyema]

Автор реально очень круто все описал, редко подобную инфу где-то можно встретить

[@siberiacancode]

Спасибо большое, репозиторий и примеры можно найти в описании, рад что зашло ❤

[@KVelian]

опа, 2,5 часовое режиссерское кино вышло в цифре, сюда

[@siberiacancode]

@@KVelian спасибо и приятного просмотра

[@Александр-ф9в4ю]

Zustand это здоровая версия Redux. И главное что глобальный менеджер состояний даёт - возможность вынести своё состояние "за пределы VDOM" дерева и юзать это состояние где ты хочешь и как захочешь. Контекст же придётся в любом случае поднимать наверх, если состояние из него потребуется юзать где угодно.

[@siberiacancode]

Не часто нужно состояние где угодно, но такой момент есть и в докладе про это говорится. Но зустанд это мини версия адекватного для react useSyncExternalStore

[@curseeedd]

Спасибо 🧊

[@siberiacancode]

@@curseeedd спасибо за коммент и просмотр 😎

[@khmilevoi]

Капец у тебя мысль скачет. Мне кажется, нужно было последовательно все раскрывать и последовательно все примеры показывать. Но вообще работа большая, конечно, респект.

[@siberiacancode]

Ну я в этом плане шизик и многие вещи приходил уже во время доклада, но все равно был определнный план и повествование, так что надеюсь основный посыл понятен

[@focusnikful]

Как же ты быстро тараторишь, иногда кажется что я вообще на ускоренной скорости воспроизведения смотрю)

[@siberiacancode]

Тот самый стример, которого не ставят на 2x

[@xdFOrfq8VVH6j5kXAh]

@@siberiacancode вопрос привычки. Смотрю х2, всё прекрасно :)

[@izzy7541]

Какая БИЗНЕС логика есть в форме авторизации? Форма собирает ввод пользователя и на кнопку Отправить вызывает экшн любого стора, куда передаст введённые данные. Нет здесь никакой бизнес логики, это самая настоящая UI логика

[@siberiacancode]

Ui логика это работа ввода и вывода данных, валидация, доп сайд эффекты, которые были показаны с полем email например чистой воды бизнес логика, ну и конечно on sibmit. В этом и большая проблема, что люди не понимают, что есть бизнес логика Ввод значений и отображений в инпуте да, но даже тут может быть бизнес логика в зависимости введнего и отображаемого

[@izzy7541]

@@siberiacancode И валидация (на клиенте) никак не связана с бизнесом, это всё также UI. А про сайд эффекты, ну, смотря какие. Если вы в компоненте делаете на onSubmit запросы куда-то и в зависимости от ответа что-то ещё делаете, то тут скил ишью как говорится. Не нужно так делать и не будет смешивание бизнес логики и UI. Отдайте введённые данные во внешний стор, там обработайте, сделайте нужные сайд эффекты и будет вам счастье

[@jeesson_]

@@siberiacancode Твои рассуждения смешивают UI-логику и бизнес-логику: базовая валидация ввода, например, проверка формата email и обработка событий формы - это задачи UI, тогда как бизнес-логика включает правила, зависящие от доменной специфики. Перекладывать ответственность за доменные решения на UI усложняет поддержку и тестирование приложения, поэтому важно четко разделять обязанности компонентов.

[@siberiacancode]

@ я описал это уже в тг, что некоторые валидации уже стали дефолтом ux, но твои размышления ломается, если я скажу требования, что например в сервисе имена Дима забанены, написать под полем это ui, а вот вычислить этот кейс это бизнес логика.

[@jeesson_]

@@siberiacancode Так это и имелось в виду. Вычисление запрета имени - это бизнес-логика, а вот показать ошибку под полем - чистая UI-логика. Поэтому важно их разделять, чтобы не запутывать код и не смешивать ответственность.

[@Lexusalex132]

Для тех кто не использовал state manager для понимания сложно.

[@siberiacancode]

Ну рано или поздно все с этим в каком-то виде столкнуться и надо четко понимать инструменты и лимиты

[@v1va53]

Не упомянуть MobX очень большое упущение Как по мне самая крутая штука, которая разносит в пух и прах все перечисленные инструменты

[@siberiacancode]

Mobx не был рассмотрен и в конце я поднимаю эту тему, потому-что мобкс полностью использует по другому реакт. Но в мобкс есть такая же проблема, как у всего кроме reatom и effector - это экосистема. На мобкс все придется писать самому, да фабрику легче сделать, но все же

[@v1va53]

@@siberiacancode я соглашусь с этим. Но и на счёт всё писать самому - палка в двух концах. MobX не требует уж слишком много кода, зато он понижает порог вхождения в проект (просто понимать что такое классы и обсервер), о чем говорилось в начале доклада

[@siberiacancode]

@@v1va53 важно, я и не говорил, что какие технологии плохие, я лишь хотел показать некоторые аспекты и мысли. Ничего его о против мобкс не имею

[@jeesson_]

@@siberiacancode выглядят как попытка оправдать предвзятость, без конкретики. Говоришь про «экосистему», но сам избегаешь объективного сравнения. Для разработчика такие поверхностные аргументы - слабая позиция.

[@siberiacancode]

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

[@farikweb]

Оч много воды

[@siberiacancode]

Я даже не знаю, хорошо это или плохо, но а вообще хотел бы узнать, что конкретно было в воде

[@injty]

не жалуйся, вода источник жизни.

[@siberiacancode]

@@injtyaqua 🎉

[@empatij1730]

@@injty 😂😂😂

[@cvtmyveins]

Автор в начале видео: "всё плохо, нет единого инструмента, много маленьких контекстов" 47 минута, автор: "redux устарел потому что он один и большой" + "rtk query это не то, что позволяет писать 'всё на редакс' потому что хуки..." с головой всё в порядке? Реакт это хуки. Это не функциональное программирование, потому что у тебя слишком мало контроля над пропсами, ты вынужден самую важную вещь в современном реакте - хуки, использовать в функциях как грязную внешнюю зависимость. Единственный способ это клепать интерфейсы для того, что нужно передавать в ui через хуки и отдельно клепать для каждой новой подключаемой библиотеки адаптеры под этот интерфейс. Все адекватные люди уже давным давно держат в проекте чистую архитектуру и отдельно есть папочка с реактом (с ui) Именно по этой причине популярен next, потому что реакт настолько неспособен адекватно интегрироваться с логикой

[@siberiacancode]

Я может с другой планеты или чего-то не видел или не понимаю, большинство проектов вообще не имеют заложенной архитекутры, как раз большинство проектов просто берут условный "redux" ну потому-что исторически так сложилось. Доклад, как раз в том числе о том, что не обазательно react использовать только для ui, ну и опять же рынок доказывает мои слова (хоть это и по mvvm или подобного) Ну часть про rtk query я вообще не понял, redux не устарел, redux не удобен из-за сингл стора, ну и основной моей тейк, веб прекрасен из-за его нетабильности, тебе не нужно в простой проект тащить чистую архитекутур и жесткое разделение и наоборот, когда ты захочешь ты можешь это сделать, хоть и с ньюансами. Об этом и есть мой доклад, что используйте инструменты, а архитектура это тоже инструмент, только когда вы выходите за лимиты и необходимости

[@cvtmyveins]

@siberiacancode Стейт менеджеры (не сами Стейт менеджеры, а концепция получения стейта и всего остального не через пропсы а как внешней зависимости) это уже грязная концепция, и тогда какая разница сколько у тебя сторов? Я имею ввиду что если проект настолько маленький что ты используешь какой-нибудь сторонний стейт-менеджер лишь бы сделать побыстрее - ты не пострадаешь от лишних ререндеров от редакса, а если проект большой - ты понимаешь что если у функций есть внешние зависимости, то проект непереносимый, неустойчивый к изменениям, нетестируемый и придётся использовать не реакт, особенно если в проекте есть потребность реактивного стейта. Очень забавно что слово "реактивность" присутствует в названии только у реакта, который сейчас чуть ли не единственный НЕ реактивный Фреймворк (те кто не понимает о чём я - пересчитывание всего на каждый пук это не реактивность, это скорее похоже на перезагрузку всего приложения если в БД таблица изменилась, настолько это нелогично). И в языке и в вебе уже давно есть куча функционала из которого можно было бы делать невероятно крутые вещи, но эти апи слишком сложны чтобы использовать их напрямую в проектах, для этого и нужны библиотеки и фреймворки, а в реакте все делают вид что они застряли в 2014-15 году (для того чтобы работало на старых устройствах? Но такая проблема возникает только на крупных проектах, для которых, как я уже написал выше, реакт не подходит...). Есть только проблема в том что вокруг реакта уже построено невероятно много всего, тот же реакт нейтив... Реакт не будет меняться ещё очень долго, если вообще будет, поэтому если и приходится писать на нём - используют старый знакомый инструмент. Повторю, нам не изменить реакт, он такой каким его сделали разработчики, а именно построен на концепции постоянных ререндеров и хуков. Нам, тем кому уже привычно писать в функциях и при этом контролировать состояния +- вручную (а не как во вью, хотя в composition API есть рефы и пр) нужно думать как написать новый фп фреймвойк/библиотеку для проектирования РЕАКТИВНОГО ui (на новом апи, не оглядываясь на тех кто не хочет обновлять устройства. Те кто не хочет обновлять устройства не нуждаются в сайтах сложнее чем пишут на jQuery, они в интернете пользуются сайтами вроде Bayer который сделан на HTMX (0 интерактивности, только поддержка старых устройств); мы же хотим DX и чего-то современного? Так давайте сделаем!). У меня просто подгорает что все пытаются реанимировать реакт и выдумывают новые библиотеки вместо написания нового фп ui Фреймворка, поэтому, автор, извиняюсь, зря быканул. Вот кстати идея для серии стримов/роликов: крупный проект сообщества по созданию нового Фреймворка в который бы всё заинтересованное сообщество канала бы делало пулреквесты

[@Михаил-я9с]

Для начала, спасибо. Автор молодец. А теперь чуть-чуть критики. 1. Не зря на конференциях есть ограничения по времени. В видео есть много повторений и выражений мнения автора, не всем интересно это видеть и слушать. Для технического доклада важнее факты, так как это скорее научная работа, чем развлечение. 2. Автор желает видеть ООП и не взял Mobx в сравнение. По меньшей мере это упущение. 3. Реклама своих продуктов это хорошо, но это не относится к теме доклада. Больше подошли бы коротенькие отсылки на видео, где эти продукты применяются, которых, кстати, я не видел на канале (здесь я могу ошибаться, так как не смотрел абсолютно все видео автора, но за последние полгода отдельных видео по продуктам автора не встречал, лишь их упоминания) 4. Если автор хотел провести интерактивный доклад, то использование + и - в чате не самый удобный формат. Сапожник без сапог, как говорится. Не думаю, что так сложно оформить сайт, где можно в режиме реального времени вести диалог со зрителями.

[@aleksandrsadchikov3704]

Не согласен про использование чата. Прежде всего это делалось для стриминговых платформ и такого формата, а без чата тут никак, это общение + байт на активность. И зачем делать отдельный сайт для диалога это бред полный, какой смысл если есть стрим. Лишнее время тратить?

[@siberiacancode]

Привет, спасибо за фидбек 1. Это мой канал и моя конфа, я имею ввиду, что весь доклад и так мое мнение, но если задуматься очень много таких докладов, тут мы обсуждаем много субъективных вещей, поэтому в этом ничего плохого не вижу, кто слушает, кто-то нет 2. Мобкс не взял по нескольким причинам, первая причина это мало на нем опыта, вторая причиная, там я бы получил такую же проблему, как на редакс связанную с экосистемой, но тестить и писать саму логику там в разы проще тут тру, ну и фабрики тоже делать намного легче

[@siberiacancode]

3. Опять же не совсем понял тут, потому-что ребята на конфах часто так делают, взять тот же reatom или effector. Доклад один способов популизации, ну и тем более это мой канал и я действительно использовал свои технологии и почему бы не показать как я это делал

[@siberiacancode]

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

[@siberiacancode]

@@aleksandrsadchikov3704да тут каждому свое, по цифрам могу сказать и по своему ощущению, что получилось супер топ, мне лично понравилось и все кто ждали доклад тоже