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

Слыша фразу “реактивное программирование” в React, большинство думает об инструментах типа RxJS, но надо помнить, что реактивное программирование - это парадигма, а не инструмент. И сегодня мы рассмотрим как эта парадигма была применена в реальных проектах
Забрать бесплатные ресурсы и 4000 бонусов от Cloud․ru можно на сайте: sc.link/GOnZX
ТГ канал - t.me/it_sin9k
Поддержать Айти Синяка можно здесь:
KZbin: / @it-sin9k
boosty: boosty.to/sin9k
Patreon: / itsin9k
00:00 Анонс темы
00:30 Машинка на халяву
01:54 Что такое реактивное программирование
03:50 Инструменты
05:55 Реактивная инициализация проекта
07:43 Изучаем пример в разрезе
09:30 JSX нюансы
10:20 Итоги подхода
11:31 Чистые инструкции
Подписаться на канал: / @it-sin9k
Twitter: / it_sin9k

[@ivanp7697]

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

[@it-sin9k]

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

[@user-kt1kx6th7z]

hello

[@ivanp7697]

@@user-kt1kx6th7z world

[@ailabinsev]

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

[@RussianFrontend]

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

[@zeromvx4343]

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

[@it-sin9k]

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

[@badcoder1337]

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

[@andyjs666]

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

[@mrkva1367]

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

[@it-sin9k]

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

[@alexanderskusnov5119]

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

[@HEX_CAT]

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

[@SckottJackson]

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

[@BogdanPolonsky]

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

[@SckottJackson]

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

[@it-sin9k]

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

[@user-sr5ts2jz7e]

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

[@BogdanPolonsky]

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

[@user-un4xi6nb2u]

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

[@it-sin9k]

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

[@golden_smiles]

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

[@it-sin9k]

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

[@user-uw9xp8en3v]

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

[@someChicoRy]

🔥🔥🔥

[@egorovsa]

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

[@it-sin9k]

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

[@grol5555]

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

[@user-ik7rp8qz5g]

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

[@it-sin9k]

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

[@NoName-zh7cc]

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

[@it-sin9k]

спасибо!)

[@hitmen061]

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

[@alexanderskusnov5119]

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

[@filcondrat]

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

[@it-sin9k]

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

[@deantek]

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

[@it-sin9k]

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

[@deantek]

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

[@CJIu3eHb]

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

[@deantek]

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

[@aleksprimetv]

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

[@user-qn5mu3eq2w]

sin9k, идёшь на HolyJS?

[@it-sin9k]

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

[@dalisoft]

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

[@andreyrudin2286]

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

[@andreyrudin2286]

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

[@azabroflovski]

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

[@corvus278]

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

[@user-uw9xp8en3v]

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

[@j1nger417]

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

[@azabroflovski]

+

[@azabroflovski]

vue

[@DavidTch]

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

[@vadimmasaltsev5292]

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

[@user-eb5yw9ui6o]

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

[@NEAmico_mat]

First

[@titsex]

Микрофончик шумит(