Комментарии 25
Жесть, аж кровь из глаз идёт глядя на всё это. Ребята, открою вам страшную тайну, есть такая штука — называется MobX. Вот ее то и нужно использовать в связке с реактом, увы больше никаких альтернатив нет, только лишь убожество.
Насчёт связки с Реактом: выглядит сложно. Не вижу смысла отказываться от стейтманагеров, там это всё из коробки.
В самом хуке имеется хрень - плотная мутабельная работа со стором вне useEffect. Небольшая засада в том, что надо возвращать store.current.value, потому всю эту работу не получится просто взять и обернуть в useEffect, но судя по всему, тут достаточно оставить "снаружи" только вычисление возвращаемого значения, а стор как-нибудь переживет запаздывание, он всё равно не вылазит наружу и не используется в рендере.
Пример с отправкой подарка не впечатлил - на промисах (через async/await, конечно), это делается проще. Единственное, что тут придется модалки авторизации/подтверждения/etc тоже промисифицировать, но это не проблема.
Promise это значение, а Observable - процесс. Основной недостаток промисов внутри эффектов - цепочку промисов невозможно кансельнуть когда компонент анмаунтится (а если расставлять внутри проверки наподобие AbortController у fetch, то код становится ещё страшнее, чем на RxJS).
В приведенном варианте sendPresent после каждого шага делается проверка положительного результата. Причем в старом добром колбэчном стиле из нулевых: код неудержимо растет в ширину и едет вправо. При использовании async/await эта проверка навтыкается между авайтами: if (!success) return; Да, лишние строки, зато код остаётся "вертикальным". Понимаю, что дело вкуса, но мне вертикальный код нравится больше.
Да, код лучше писать максимально просто и примеры в статье выглядят спорными (как будто чисто императивное решение написали операторами). Но сам опыт в целом интересный.
Обычно RxJS приносит с собой массу особенностей и проблем: отдельную парадигму реактивного программирования, функциональный стиль, проблемы с поддержкой, отладкой и автотестами. К тому же это низкоуровневая библиотека, а не готовое решение какой-либо насущной задачи. Observable уже давно пытаются притащить в стандарт, но результатов пока нет, да и энтузиазма кажется с годами уже поубавилось. Microsoft вроде бы и сами его не шибко используют.
Есть готовая реализация стопы на основе RxJS - Ngrx. Заточена конечно под ангуляр (как и ангуляр под rxjs) но мб и с реактом мб юзабельно.
Можете назвать какие-то плюсы для использования RxJS вместо Redux, кроме как бойлер плейт(уже есть redux-toolkit) и удобной асинхронной логиков(с чем я бы поспорил)?
Ведь если взять даже ваш пример с получением данных из моделей, то нужно дернуть модель, пайпать этот стрим и потом заюзать операторы для получения 1 значения. Если бы это было бы написано на редаксе, то просто делаем селект на нужное поле и можем выйти покурить, пока rx разработчик дописывает обработку своего стрима из модели.
Как доп, вам получается нужно реализовать свою модель с использованием RxJS и удобным доступом, для получения значений из нее.(те реализация стора, которая есть у Redux из коробки)
Redux очень хорошо дебажится практически из коробки для веба и rn. Есть что-то подобное для RxJS?
По поводу плюсов, соглащусь, что пример, приведенный в статье не удачный. Плюсов конкретно этот пример не показывает. Стараясь максимально не шарить код бизнес-логики продукта, придумал не удачный пример. В отдельной статье или может быть отдельно в gist добавлю пример получше.
По поводу модели, да, мы реализовывали свои модели/сторы, максимально удобные для нашей работы. Но RxJS можно как и писал в статье подружить с другими решениями (Redux, MobX, ...).
По поводу дебага, опять таки, RxJS это лишь способ декларативно написать бизнес-логику. Тут сравнение с Redux не до конца уместно. Понятно, что раз в RxJS нет сторов из коробки, то не будет и всего того многообразия инструментов для работы со стором, action-ами, которые есть у Redux.
Но RxJS можно как и писал в статье подружить с другими решениями (Redux, MobX, ...).
Можно, но имхо не нужно. Искусство программирования - это ведь про уменьшение сложности, и про прогнозируемое управление ею. Зачем увеличивать энтропию на ровном месте? Плюс дополнительные риски по поиску сотрудников.
На тот момент активно развивались и пользовались популярностью фреймворки Redux и MobX, однако они не упрощали работу с пайплайнами относительно Flux, а Redux также требовал на порядок больше бойлерплейта. В общем, везде свои проблемы.
А можно у вас попросить пример того как бы вы написали аналогичный sendPresent код на Redux и MobX? Мне вот не очевидно, что код на генераторах (через redux-saga или через встроенные в MobX flow) будет менее понятным.
Большое количество встроенных операторов позволяют не тратить время на изучение того, что происходит в коде, а сразу понимать это по операторам.
Шило-на-мыло. А трата времени на изучение большого количества операторов?
Большинство операторов имеют понятный из названия и интерфейса функционал. Но соглашусь, что есть те операторы, поведение которых придется читать в документации, т.к. оно не явно.
Документацию к rxjs надо изучать, да. Но потом зная набор инструментов ты экономишь кучу времени и строчек кода. И затраты времени на изучение документации окупаются.
Это как с reduce у массива. Сначала пытаешься в голове уложить как это работает. А потом не понимаеш как жил без него.
Предлагаю заценить вот эту демку и посмотреть как работает метод zip например. https://www.youtube.com/watch?v=IXBiUmnd0Pk . У меня был кейс когда он мне был нужен. Оцените за сколько времени вы напишете аналог. Тут нет ничего сверхъестественного и всё осуществимо конечно. Но в rxjs он уже есть, отлажен и оптимизирован. И многое другое.
Странно что тут вообще сравнивают mobx и rxjs, это совсем разные инструменты, мы давно используем rxjs и mobx, это отличная связка.
Как автор правильно написал в одном из комментариев, преимущество использования rxjs особенно наглядно видно при обработке большого количества повторяющихся событий. Для одиночных событий есть промис и огород городить не надо.
Надо понимать, что события могут приходить из разных источников и сыпаться в перемешку. Когда логика приложения предполагает четкую последовательность действий, то от rxjs нет никакого выхлопа. Идеально подходит вариант писать "вертикально" через async/await. Получил запрос от пользователя - проверил авторизацию - сходил в бд за данными - посчитал чего-то - отдал ответ. Async/await и голову забивать не надо. Но представьте, что во время ожидания ответа из бд (уж простите мой бэковый уклон, но мне сейчас так проще) произошло какое-то событие, после которого один из шагов await больше выполнять уже не нужно, один серьезно видоизменяется, а один добавляется новый. Ну фиг знает, изменилась котировка акции ниже порогового значения и теперь на услугу А компания больше не готова предоставлять скидку которую запрашивает пользователь, а продажу товара Б теперь надо заморозить на 4 часа. И таких условий может быть не одно, если после каждого шага проверять условия через if то всё очень скоро превратится в большой комок грязи.
А с rxjs такая логика пишется очень компактно и декларативно. Без конкретных примеров мои слова конечно выглядят голословно( Но это всё равно моя позиция.
Попробую описать один кейс, после которого вся наша тогдашняя команда влюбилась в rxjs. Пример кода к сожалению сейчас не найду. Жаль конечно, без него всё не так наглядно.
Есть график с несколькими столбчатыми диаграммами, на котором отображается мониторинг состояния некоторых устройств. По веб-сокету постоянно сыпятся сообщения об актуальном состоянии устройств, на каждое событие график приращивается. Сверху графика есть несколько селектов с параметрами фильтрации - производитель, модель устройства, временной интервал, хорошие/плохие/все события, и ещё фиг знает что, не помню. При изменении значения в селекте делается хттп запрос на сервер для получения стартовых значений для нового графика. Пока ожидаем ответ по хттп, график перестаёт прирастать от событий из ws так как пользователя эти данные вроде уже не интересуют. При этом в угла страницы есть несколько крупных строчек с наиболее важными показателями тех. процесса, значения селектов на которые не влияют. Эти данные получаются из тех же событий ws и они соответственно должны актуализироваться.
Человек (вот кстати не помню, может это был и я :) ) сначала неэстетично лавировал между ифами. А потом чел который у нас уже давно был с rxjs, показал как можно это всё завернуть в несколько потоков и по определенным правилам эти потоки мёрлжить/разводить. Кода получилось меньше раза в 3 и он был наглядный. А мы собрались вокруг монитора как дети вокруг Банифация и радовались глядя на код.
Если повезёт и я найду тот код - приложу его позже.
При изменении значения в селекте делается хттп запрос на сервер для получения стартовых значений для нового графика.
Не знаю всех подробностей, но схема со стартовыми значениям по хттп и их изменениями по вебсокету выглядит как хрупкая и с лишним дублированием на бэке. Логичней было бы по хттп делать только фильтрацию (получать набор id), передавать этот набор в вебсокет для наблюдений (все значения - с вебсокета) и заодно знать какие графики будут на экране. А с вебсокета просто обновлять значения в мобиксовом сторе. Если нормально всё декомпозировать, то получается просто и понятно.
Попробую описать один кейс, после которого вся наша тогдашняя команда влюбилась в rxjs. Пример кода к сожалению сейчас не найду. Жаль конечно, без него всё не так наглядно.
Естественно никакого кода у вас нет и не было, тем более вы его не приложите, т.к. это вырвиграз. Самое стандартная отмазка — ну короче все ништяк, но кода я вам не покажу.
А потом чел который у нас уже давно был с rxjs, показал как можно это всё завернуть в несколько потоков и по определенным правилам эти потоки мёрлжить/разводить. Кода получилось меньше раза в 3 и он был наглядный. А мы собрались вокруг монитора как дети вокруг Банифация и радовались глядя на код.
Наглядный код в RxJS — смешно. В 3 раза меньше? Если вы написали плохой код / плохой алгоритм, это не значит что по человечески нельзя написать, да и размер кода не важен, важна его наглядность, очевидность и простота. Задача которую вы расписали достаточно элементарно решается средствами React + MobX, Vue.js, Svelte. Если вы измеряете качество кода кол-вом строчек, то у меня для вас плохие новости.
А мы собрались вокруг монитора как дети вокруг Банифация и радовались глядя на код.
Ну все понятно с вашей компетенцией тогда)
Как связка React и RxJS улучшила код и ускорила разработку мобильных приложений