EDA подход в Angular

[@vintage]

EDA — это антипаттерн в большинстве случаев.

[@Demetros]

Использование $rootScope.$broadcast — не лучший пример, такое событие будет спускаться по иерархии скоупов и возникать на каждом.
Ну и конечно неизбежно возникают гонки, когда событие сгенерировано, а получатель еще не подписался на него.

[@silentvick]

Не во все скоупы, к счастью, а только в те, которые содержат слушателя для данного события (внутри самого скоупа или его потомков). По крайней мере, в свежих версиях angular-а.

Scope.$broadcast() Is Surprisingly Efficient In AngularJS

[@enepomnyaschih]

Оптимизация $broadcast ценой тормознутого $on и отписки. Окупится только если событие бросается из scopes, приближенных к корневому. Ближе к веткам порождает больше накладных расходов, чем приносит пользы. Отличный пример того, как Angular скрывает проблему архитектуры, не решая ее.

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

[@extempl]

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

Облегчает? Да. Прозрачной? Серьёзно? Да код превращается в макароны, где не видно, что откуда растёт и где заканчивается. А если продебажить? Попробуйте. А лучше в проекте, который вы видите впервые.

[@extempl]

Хотя, справедливости ради, стоит отметить, что при правильном подходе именования ивентов с использованием NS, вполне можно проследить код. Не дебаггером, конечно, но глобальным поиском по коду можно.

[@lalaki]

[описываемый подход] сильно облегчает разработку, когда связанные компоненты находятся на разных ветвях иерархии

Надо просто не усложнять разработку изначально — не связывать компоненты на разных уровнях иерархии.
Для этого есть простая совокупность правил проектирования, не зависящих от фреймворка:

• Компонента (часть UI) может знать только о своих непосредственных потомках (которых она так или иначе и создала)
• Компонента-родитель при создании передает непосредственному потомку данные, нужные ему для работы (+ опционально дергает его методы интерфейса), и слушает его события — тупо передает ему обработчик, который надо дернуть
• Компонента-потомок не знает о родителе — только генерирует события, а точнее, просто дергает полученные обработчики
• Все дополнительное взаимодействие организуется через сервисы («вечные» единицы бизнес-логики): сервисы уже генерируют полноценные события, на которые может подписываться множество слушателей (других сервисов или компонент), с учетом жизненного цикла слушателей (для Angular это — автоотписка компоненты при уничтожении ее scope, как в примере в статье

[@Fesor]

Я некоторое время занимаюсь разработкой на Angular и использование EDA подхода сильно помогает в создании приложений.

А вы другие подходы пробовали? EDA далеко не для всех задач будет удобен. По своему опыту, EDA подходит для сильно связанных систем, например игрушки. А web приложеньки — там в 99% слуачев больше проблем.

Далее, использование событий $scope вне жизненного цикла директив/компонентов — антипаттерн, не для того эта штука там нужна. Я даже правило в eslint добавить вот планирую, что бы не пропускало коммиты где $scope используется вне link директив.

большое количество возможных событий, то количество watchers

С каких пор использование событий влияет на количество ватчеров? Да и ватчеры использовать необязательно в принципе для отслеживания изменений, можно просто сеттеры юзать и тогда все хорошо будет.

магическое число 2000 давно перевалило за 100к.

Оно изначально было ~100К. Фраза про 2000 была о том, что если у вас 2000 ватчеров на скрин, значит вы что-то делаете неправильно. Да и производительность ватчеров меряется не их количеством, а временем их работы. Простые ватчеры, которые втупую сравнивают все по ссылке — их может быть и 100К, а добавить один дип ватч на жирный объект который часто меняется, и он один уже убьет всю производительность.

В целом — ватчеры в коде самого приложения вообще не нужны. Они нужны только самому ангуляру для работы биндингов, но не более того. Ну и еще директивы-примитивы для работы с DOM например, которые отслеживают изменение состояния и мутируют DOM.

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

А вы когда-нибудь дебажили приложение построенное на этом подходе? Это ж маленький ад. А как это тестировать? Мокать везде менеджер событий? EDA используют в геймдеве, потому что там это единственный адекватный вариант как-то снизить связанность между компонентами без потерь производительности. В разработке приложений — это так себе подход.

[@Werawoolf]

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

[@Fesor]

если грамотно спроектировать

С этим нынче проблемы. Именно по этому использование таких подходов легко превращаются в боль и страдания.