Комментарии 9
Есть ли у данного паттерна преимущества/недостатки в сравнении с Provider ?(https://pub.dev/packages/provider)
Вопрос задаю по причине того, что указанные Вами преимущества паттерна не относятся к Provider (кроме преимущества, что не надо использовать сторонние пакеты - сам Provider является сторонней библиотекой).
А можно в ListenCubit передавать не весь CounterCubit а только Stream<int> и тогда жесткой зависимости нет, проще тестировать и переиспользовать.
Имхо в реактивном языке, где что угодно можно сделать стримом, EventBus не нужен.
Используем в проде эту имплементацию, нареканий нет. Просто и удобно.
От евентбаса в мобильной разработке отказались уже лет эдак 8 назад. Именно как от концепта общей шины. И именно на больших и сложных проектах. Все дело в том, что при достаточно большом количестве гоняемых данных может возникнуть необходимость по-разному обходиться с backpressure, иметь разнообразные (горячие и холодные) стримы (а шина всегда горячая), а так же (что неактуально для дарта) исполнять обработчики цепочек на разных тредпулах. Плюс отлаживать на общей трубе крайне мерзко, потому что правило единого эмиттера конвенциональное, а не контролируется компилятором. Честно-честно, я приходил на проекты с евентбасом и это боль.
Отказались в пользу реактивных стримов на источниках конкретных типизированных данных. Обычно это библиотека "rx[Вставьте свой любимый язык]". RxDart в том числе. То что вы написали называется в rx-терминах PublishSubject (если передвинуть дженерик наверх в сам класс), правда урезанный, обычно у него есть буфер и стратегии поведения при переполнении буфера (backpressure strategy) есть еще один - с фиксированным и обязательно заполненным (seeded) буфером размером в 1, он называется BehaviorSubject и чертовски подходит как раз для UI-стейта в bloc и других разных MV*. Или для выноса в репозиторий.
Таким образом нашим сопричастным к счетчику кубитам остается только дернуть метод репо для инкремента счетчика и подписаться на типизированный стрим счетчика, отдаваемый репозиторием. Иногда потребителю нужны многие стримы и композить их в единый ивент можно при помощи разных combine/merge.
От самого Rx в нативном дроиде тоже отказались в пользу котлиновских Flow, но это уже другая история, тем более что у нас тут дарт. Можно пользоваться или не пользоваться rx, сами стримы в дарте достаточно мощные, но вот использовать именно EventBus я бы крайне не рекомендовал.
Ну во первых вы неправильно работаете с блоком. В офф доках описаны 2 способа взаимодействия их друг с другом. Внедряя их друг в друга через конструктор вы создаете тесное связывания которое пытаетесь решить через ивент бас. В результате вы получаете синглтон/god object, который будет глобальным. Это такой аналог редакса по сути. Смысл блока в том чтобы разбить логику на несвязанные между собой куски, мультисторы, на каждую фичу по блоку. Я бы и не писал бы если бы сам не пытался связать блоки через event bus когда только начинал карьеру во флаттере. Но пообщавшись с феликсом на гитхабе отбросил эту идею. Возможно концепция имеет место быть но для очень специфических задач.
Event Bus: пишем шину событий во Flutter-приложении