Варианты реактивного программирования в реальных проектах (не RxJS)
HTML-код
- Опубликовано: 3 июн 2024
- Слыша фразу “реактивное программирование” в React, большинство думает об инструментах типа RxJS, но надо помнить, что реактивное программирование - это парадигма, а не инструмент. И сегодня мы рассмотрим как эта парадигма была применена в реальных проектах
Забрать бесплатные ресурсы и 4000 бонусов от Cloud․ru можно на сайте: sc.link/GOnZX
ТГ канал - t.me/it_sin9k
Поддержать Айти Синяка можно здесь:
RUclips: / @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
У нас довольно старый и очень большой проект, у которого несколько раз менялся главный мейнтейнер. И каждый новый приносил свое видение «прекрасного», начинал это внедрять, а потом на полпути либо сам уходил из проекта, либо его уходили. В итоге у нас сейчас в проекте и саги, и rtk-query, и просто редакс, и довольно большой пласт логики просто в глобальном контексте лежит, а в стилях у нас и css модули, и styled components используются. Я этот подход называю: «пишу, как в кайф»😅
ахахах) наболело) я не раз приходил такие проекты зачищать))
hello
@@user-kt1kx6th7z world
сочувствую...
На текущей работе около 10+ проектов, везде используем mobx на реакте. Лучше системы реактивности не видел. Просто , понятно, удобно , гибко. Хочешь синглтоны , хочешь через контекст , хочешь view model local, и ТД. Все что существует можно реализовать на mobx , но нужно следить за архитектурой , ТК мобкс такой же гибкий как и реакт
По поводу MobX. Сейчас декораторы - deprecated и все юзают makeObservable и makeAutoObservable. Также никто не мешает писать чистые инструкции используя Mobx. Все зависит от того, как спроектировали систему.
в том проекте люди злоупотреблялии именно reaction( .. ) когда ты можешь подписаться на что то и реагировать. И там был прям целый пинг понг событий) но в итоге мы тоже перешли в рамках mobx на чистые инструкции и все стало норм работать) поэтому я и говорю, что нужно обсуждать не инструменты, а подходы написания кода)
@@it-sin9k У тебя проблема с реализацией. Везде где используется redux это прямой путь на дно, а ты говоришь "нужно обсуждать не инструменты". Как раз таки в инструментах проблема. Можно что угодно в какой угодно подход записать. Но redux и его производные как были мусором так и останутся.
Выкинули effector, затащили MobX, запретили в нем реакции регламентом и кайфуем от чистого кода
А можете в двух словах написать, что пошло не так с Эффектором?
Привет, Айти Синяк и его команда. Вы лучшие
Привет ;-) спасибо!
Да нет, обычные рекламщики. минус
Используем на проектах effector.
Если заранее продумывать схему потока данных и не перебарщивать со сложностью, то вполне удобно с этим работать
Приветик)
Мне кажется тут сильно от масштаба проекта зависит, например если всё приложение это небольншой монолит, где можно заранее продумать все потоки данных, тогда в реактивном подходе хоть с тем же эффектором всё будет окей.
Но если проект становится настолько большим, что приходится переходить на микрофронты, то каждый из них внутри может и пусть будет реактивным, но связи между ними не стоит делать реактивными, слишком велик шанс поменяв в одном месте разрушить что-то в другом.
Опять же, всё утыкается в продумывание заранее. А потом переделывание всего потока данных если оказалось, что бизнес требования поменялись.
@@BogdanPolonskyОо, привет, неожиданная встреча)
Абсолютно согласен с тобой - микрофронты, как и любые другие юниты приложения, стоит делать менее связанными
вот тут самое сложное) продумать схему потока данных, донести ее до всей команды в 20 человек. И при этом надо как то не переборщить со сложностью, а это зачастую самое сложное))
Года 3-4 назад пытался с ним поработать
вообще не понравилось
@@SckottJackson да, неожиданная встреча)) хотя мне кажется сейчас много кто синяка смотрит в комьюнити, так что можно знакомых встретить)
Спасибо за видео! Отслеживать через редакс саги совсем не сложно, достаточно подключить мидлварку для логирования (редакс сага работает по принципу конвейера мидлварок) и она показывает каждый задиспатченный экшн в деталях
спасибо!) хорошая идея) звучит как будто дебажить микросервисы на бэке) сугубо по логам)
@@it-sin9k Это вообще-то главное преимущество редакса, как раз. Всегда понятно какой акшен прилетел и что произошло по логам. Удивительно, если ктото этого не делает, если говорить о больших проектах.
я обычно минимизирую использование редакса до минимума) что можно локально хранить, храню локально) а что надо глобально, то уже только тогда. В итоге и дебажить особо ничего не нужно, так как там простые вещи)
@@golden_smiles я думаю, это не преимущество, а вынужденная мера, так как стейт глобальный
@@user-uw9xp8en3v Никто не заставляет держать ВСЕ в глобальном стейте. Да, я помню, были времена активной агитации за это, уже охладели, в прошлом оставили. Но иногда без него никак. Вообще есть точка зрения, что стейт менеджеры не нужны особо, так как большинство юз-кейсов уже выделено в специализированые хуки-библы, типа Query. Но повторюсь, ИНОГДА без него никак, или ИНОГДА с ним удобнее. И тогда я не понимаю, как пользоваться стейт менеджером без логирования, потому что стейт минимум не локальный в таких случаях ВСЕГДА. Что когда поменяло его - можно понять только по логам. И не важно, Редакс или чтото еще, но в Редаксе эта проблема решена элегантно.
Привет. Спасибо за видос, как всегда интересно. Но вот насчет редакс-саги я не совсем понял. Если мобыкс таки да, поскольку там сеттеры(хз как щас , раньше было) оверрайднули, то сага таки нет, ибо это просто реализация мидлы, как и танки итд, но на генераторах. Проще мне думается было бы просто сказать Редакс и Мобыкс ,
мы обсуждаем инструменты) а реактивное программирование можно достичь на огромном количестве инструментов) по факту, если есть поток событий, на которые реагируют, то это уже большой шаг в стороны реактивщины)
На проекте используем rtk query с тэг провайдерами и всё как-то само обновляется)
У нас на проекте в качестве стора реактивный effector, выкинули mobX. Ну нет проблем, которые описаны в видео. Как-то всё решается через event, effect и store. Если действительно «лютая» бизнес-логика, техлид заставляет рисовать диаграмму состояний, чтобы легко было понять.
Где-то 2 недели потратил на обучение, а потом как-то всё стало просто логично и понятно. Просто логика у реактивного программирования иная.
По моему опыту, реактивность нужна, когда уйма асинхронной бизнес-логики, которая то последовательная, то параллельная, то ждёт 3-х одновременных событий и ещё где-то в длинной цепочке появляется ошибка. MobX не тянет.
Работал на проекте с Redux и Redux-Saga их понять в разы сложнее, чем реактивность.
🔥🔥🔥
Согласен
Саги я лично не использовал из-за ущербного синтаксиса генераторов, но видел в интернетах такой комментарий: "Саги вам не нужны до тех пор, когда они действительно необходимы. Но тогда вам уже не саги нужны, а переписывать архитектуру приложения"
А по теме - чем такой подход отличается от шины данных? Там ведь тоже одни компоненты в шину спамят, другие на нее подписываются, отлавливают нужные события и реагируют на них.
так шина это тоже про реактивное программирование. Я не говорю, что реактивное программирование это плохо. Но это приводит в некоторых ситуациях к определенным результатам
Годный контент подъехал, благодарствуем❤
Саня, ты лучший
спасибо!)
мне кажется подход signals как в solidjs частично решает перечисленные проблемы
надо будет изучить)
Обычное функциональное программирование (мне нравится Haskell), а также DSP-процессоры.
я пытался попробовать RxJs, но мне нифига не дается, на работе с командой решили, что нам в принципе эта парадигма не нужна, просто юзаем стейт из rtk и не паримся, хотя наверно в банках такое надо
не было проекта, где мне RxJs понадобился))
@@it-sin9k я пытался связать rxjs с react-native в рамках мультичейн криптокошелька, сам кошелек с разными блокчейнами создать удалось, но вот rxjs использовать было больно(
Так rtk - тоже реактивное, как и все где есть Pub-Sub, как я понимаю. RxJS хорош там, куда его тащить спецом не надо ради пары случаев применения. Например, в том же ангуляре.
@@CJIu3eHb rtk банально проще
@@it-sin9kон лучше подходит где нужно какую то инфу с датчиков обрабатывать
Про рекламу, жалько что только от РФ можно зарегистрироваться. Хотел бы попробовать
да там уже Computed т.е. то что должно быть Free tier уже не доступно (
наврал, это в одной из форм не работал, реально создал ) 146 рублей/месяц на белый IP адрес ) работает.
sin9k, идёшь на HolyJS?
в онлайне буду смотреть)
vue
Я не знаю на основании чего rx-поделку называют реактивной. Это обычный калбек к которому прикрутили цепочку преобразований. Реактивности там ровно ноль. Подобного подходу тысячи лет он используется в sh.
Твой пример с ручной лапшой ничего не делает. Вопроса в инициализации вообще никакой нет. Инициализация в рамках динамической реактивной модели выделяется лишь потому что она строит зависимости между данными и инициализирует связи между ними. Твоя код ничего этого не делает. Вот добавился новый чат - что ты будешь с этим делать? Вызывать эту функцию заново и выкачивать всё?
Озбекистон ба пеш !!!
+
ИМХО дизайн реактивности Vue просто потрясающий, его декларативный подход делает код чистым и легко читаемым
Реактивность хороша для ui слоя, что бы не заморачиваться актуализаций ui. Но если выносить её на другие уровни, то становится очень сложно простраивать флоу логики, из-за чего очень сложно дебажить и вносить новые изменения
@@corvus278 согласен, на других уровнях не нужно. Ну, конечно, если это не какие-то потоковые данные, тогда можно тот же RxJS воткнуть на тот слой, думаю
Сама реактивность как таковая данным не сильно нужна. Особенно в вебе. Основная проблема, которую решает реактивность - это починка раеакт. Реакт максимально кривое подели. С убогим дизайном и реализацией. С нерабочими концепциями типа вдома и прочими фантазиями.
Если реакт обновлять не таргентно - он будет тормозить совсем до невозможного уровня. Обновить его в принципе невозможно. Он никак не связывает отображение и данные из которых был построен. Точно так же как твой код в пример на 11:41
Поэтому его нужно как-то обновлять. Нужны средства связывания данных/отображения вопреки всем палкам в колёса, которые вставляет реакт.
Если максимально упрощать проблему - имея id пользователя и изменения - ты можешь найти этого пользователя и применить изменения. Найти же какой компонент/дом связан с этим элементом не представляется возможным и потому все проблемы.
First
Считаю очень плохо что реакт(гей) сообщество не приняло rxjs! Подозреваю потому что им показалось это слишком сложно! А rxjs очень хорош! Очень гибкий и удобный!
Ты чего такой обиженный)
приведи примеры в каких кейсах именно?
не работал с rxjs, но хотел бы узнать о его плюшках
Микрофончик шумит(