Варианты реактивного программирования в реальных проектах (не RxJS)

[@ivanp7697]

У нас довольно старый и очень большой проект, у которого несколько раз менялся главный мейнтейнер. И каждый новый приносил свое видение «прекрасного», начинал это внедрять, а потом на полпути либо сам уходил из проекта, либо его уходили. В итоге у нас сейчас в проекте и саги, и rtk-query, и просто редакс, и довольно большой пласт логики просто в глобальном контексте лежит, а в стилях у нас и css модули, и styled components используются. Я этот подход называю: «пишу, как в кайф»😅

[@it-sin9k]

ахахах) наболело) я не раз приходил такие проекты зачищать))

[@КириллПиринен]

hello

[@ivanp7697]

@@КириллПиринен world

[@ailabinsev]

сочувствую...

[@zeromvx4343]

По поводу MobX. Сейчас декораторы - deprecated и все юзают makeObservable и makeAutoObservable. Также никто не мешает писать чистые инструкции используя Mobx. Все зависит от того, как спроектировали систему.

[@it-sin9k]

в том проекте люди злоупотреблялии именно reaction( .. ) когда ты можешь подписаться на что то и реагировать. И там был прям целый пинг понг событий) но в итоге мы тоже перешли в рамках mobx на чистые инструкции и все стало норм работать) поэтому я и говорю, что нужно обсуждать не инструменты, а подходы написания кода)

[@tgitw-tq6iu]

​@@it-sin9k У тебя проблема с реализацией. Везде где используется redux это прямой путь на дно, а ты говоришь "нужно обсуждать не инструменты". Как раз таки в инструментах проблема. Можно что угодно в какой угодно подход записать. Но redux и его производные как были мусором так и останутся.

[@RussianFrontend]

На текущей работе около 10+ проектов, везде используем mobx на реакте. Лучше системы реактивности не видел. Просто , понятно, удобно , гибко. Хочешь синглтоны , хочешь через контекст , хочешь view model local, и ТД. Все что существует можно реализовать на mobx , но нужно следить за архитектурой , ТК мобкс такой же гибкий как и реакт

[@nivabul7871]

еще в мобыксе абсолютно отсутствует любого рода бойлерпринт, кайф

[@SckottJackson]

Используем на проектах effector. Если заранее продумывать схему потока данных и не перебарщивать со сложностью, то вполне удобно с этим работать

[@BogdanPolonsky]

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

[@SckottJackson]

@@BogdanPolonskyОо, привет, неожиданная встреча) Абсолютно согласен с тобой - микрофронты, как и любые другие юниты приложения, стоит делать менее связанными

[@it-sin9k]

вот тут самое сложное) продумать схему потока данных, донести ее до всей команды в 20 человек. И при этом надо как то не переборщить со сложностью, а это зачастую самое сложное))

[@АртемТерещенко-ц4э]

Года 3-4 назад пытался с ним поработать вообще не понравилось

[@BogdanPolonsky]

​@@SckottJackson да, неожиданная встреча)) хотя мне кажется сейчас много кто синяка смотрит в комьюнити, так что можно знакомых встретить)

[@mrkva1367]

Привет, Айти Синяк и его команда. Вы лучшие

[@it-sin9k]

Привет ;-) спасибо!

[@alexanderskusnov5119]

Да нет, обычные рекламщики. минус

[@grol5555]

У нас на проекте в качестве стора реактивный effector, выкинули mobX. Ну нет проблем, которые описаны в видео. Как-то всё решается через event, effect и store. Если действительно «лютая» бизнес-логика, техлид заставляет рисовать диаграмму состояний, чтобы легко было понять. Где-то 2 недели потратил на обучение, а потом как-то всё стало просто логично и понятно. Просто логика у реактивного программирования иная. По моему опыту, реактивность нужна, когда уйма асинхронной бизнес-логики, которая то последовательная, то параллельная, то ждёт 3-х одновременных событий и ещё где-то в длинной цепочке появляется ошибка. MobX не тянет. Работал на проекте с Redux и Redux-Saga их понять в разы сложнее, чем реактивность.

[@JestNest-b8v]

Спасибо за видео! Отслеживать через редакс саги совсем не сложно, достаточно подключить мидлварку для логирования (редакс сага работает по принципу конвейера мидлварок) и она показывает каждый задиспатченный экшн в деталях

[@it-sin9k]

спасибо!) хорошая идея) звучит как будто дебажить микросервисы на бэке) сугубо по логам)

[@golden_smiles]

@@it-sin9k Это вообще-то главное преимущество редакса, как раз. Всегда понятно какой акшен прилетел и что произошло по логам. Удивительно, если ктото этого не делает, если говорить о больших проектах.

[@it-sin9k]

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

[@ПользовательПользователь-с8к]

​@@golden_smiles я думаю, это не преимущество, а вынужденная мера, так как стейт глобальный

[@golden_smiles]

@@ПользовательПользователь-с8к Никто не заставляет держать ВСЕ в глобальном стейте. Да, я помню, были времена активной агитации за это, уже охладели, в прошлом оставили. Но иногда без него никак. Вообще есть точка зрения, что стейт менеджеры не нужны особо, так как большинство юз-кейсов уже выделено в специализированые хуки-библы, типа Query. Но повторюсь, ИНОГДА без него никак, или ИНОГДА с ним удобнее. И тогда я не понимаю, как пользоваться стейт менеджером без логирования, потому что стейт минимум не локальный в таких случаях ВСЕГДА. Что когда поменяло его - можно понять только по логам. И не важно, Редакс или чтото еще, но в Редаксе эта проблема решена элегантно.

[@badcoder1337]

Выкинули effector, затащили MobX, запретили в нем реакции регламентом и кайфуем от чистого кода

[@andyjs666]

А можете в двух словах написать, что пошло не так с Эффектором?

[@HEX_CAT]

Годный контент подъехал, благодарствуем❤

[@egorovsa]

Привет. Спасибо за видос, как всегда интересно. Но вот насчет редакс-саги я не совсем понял. Если мобыкс таки да, поскольку там сеттеры(хз как щас , раньше было) оверрайднули, то сага таки нет, ибо это просто реализация мидлы, как и танки итд, но на генераторах. Проще мне думается было бы просто сказать Редакс и Мобыкс ,

[@it-sin9k]

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

[@RahmaninovSV]

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

[@hitmen061]

На проекте используем rtk query с тэг провайдерами и всё как-то само обновляется)

[@deantek]

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

[@it-sin9k]

не было проекта, где мне RxJs понадобился))

[@deantek]

@@it-sin9k я пытался связать rxjs с react-native в рамках мультичейн криптокошелька, сам кошелек с разными блокчейнами создать удалось, но вот rxjs использовать было больно(

[@CJIu3eHb]

Так rtk - тоже реактивное, как и все где есть Pub-Sub, как я понимаю. RxJS хорош там, куда его тащить спецом не надо ради пары случаев применения. Например, в том же ангуляре.

[@deantek]

@@CJIu3eHb rtk банально проще

[@aleksprimetv]

​@@it-sin9kон лучше подходит где нужно какую то инфу с датчиков обрабатывать

[@virtual5754]

Саги я лично не использовал из-за ущербного синтаксиса генераторов, но видел в интернетах такой комментарий: "Саги вам не нужны до тех пор, когда они действительно необходимы. Но тогда вам уже не саги нужны, а переписывать архитектуру приложения" А по теме - чем такой подход отличается от шины данных? Там ведь тоже одни компоненты в шину спамят, другие на нее подписываются, отлавливают нужные события и реагируют на них.

[@it-sin9k]

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

[@alexanderskusnov5119]

Обычное функциональное программирование (мне нравится Haskell), а также DSP-процессоры.

[@filcondrat]

мне кажется подход signals как в solidjs частично решает перечисленные проблемы

[@it-sin9k]

надо будет изучить)

[@АркадийКузнецов-щ4я]

sin9k, идёшь на HolyJS?

[@it-sin9k]

в онлайне буду смотреть)

[@_boolive_]

Согласен

[@dalisoft]

Про рекламу, жалько что только от РФ можно зарегистрироваться. Хотел бы попробовать

[@rudinandrey]

да там уже Computed т.е. то что должно быть Free tier уже не доступно (

[@rudinandrey]

наврал, это в одной из форм не работал, реально создал ) 146 рублей/месяц на белый IP адрес ) работает.

[@NoName-zh7cc]

Саня, ты лучший

[@it-sin9k]

спасибо!)

[@tgitw-tq6iu]

Я не знаю на основании чего rx-поделку называют реактивной. Это обычный калбек к которому прикрутили цепочку преобразований. Реактивности там ровно ноль. Подобного подходу тысячи лет он используется в sh. Твой пример с ручной лапшой ничего не делает. Вопроса в инициализации вообще никакой нет. Инициализация в рамках динамической реактивной модели выделяется лишь потому что она строит зависимости между данными и инициализирует связи между ними. Твоя код ничего этого не делает. Вот добавился новый чат - что ты будешь с этим делать? Вызывать эту функцию заново и выкачивать всё?

[@someChicoRy]

🔥🔥🔥

[@tgitw-tq6iu]

Сама реактивность как таковая данным не сильно нужна. Особенно в вебе. Основная проблема, которую решает реактивность - это починка раеакт. Реакт максимально кривое подели. С убогим дизайном и реализацией. С нерабочими концепциями типа вдома и прочими фантазиями. Если реакт обновлять не таргентно - он будет тормозить совсем до невозможного уровня. Обновить его в принципе невозможно. Он никак не связывает отображение и данные из которых был построен. Точно так же как твой код в пример на 11:41 Поэтому его нужно как-то обновлять. Нужны средства связывания данных/отображения вопреки всем палкам в колёса, которые вставляет реакт. Если максимально упрощать проблему - имея id пользователя и изменения - ты можешь найти этого пользователя и применить изменения. Найти же какой компонент/дом связан с этим элементом не представляется возможным и потому все проблемы.

[@azabroflovski]

ИМХО дизайн реактивности Vue просто потрясающий, его декларативный подход делает код чистым и легко читаемым

[@corvus278]

Реактивность хороша для ui слоя, что бы не заморачиваться актуализаций ui. Но если выносить её на другие уровни, то становится очень сложно простраивать флоу логики, из-за чего очень сложно дебажить и вносить новые изменения

[@ПользовательПользователь-с8к]

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

[@j1nger417]

Озбекистон ба пеш !!!

[@azabroflovski]

+

[@azabroflovski]

vue

[@DavidTch]

Считаю очень плохо что реакт(гей) сообщество не приняло rxjs! Подозреваю потому что им показалось это слишком сложно! А rxjs очень хорош! Очень гибкий и удобный!

[@vadimmasaltsev5292]

Ты чего такой обиженный)

[@ВладиславСвидерский-г6й]

приведи примеры в каких кейсах именно? не работал с rxjs, но хотел бы узнать о его плюшках

[@NEAmico_mat]

First