Само собой и они не проще вписываются в оригинальную сервисную модель

ну так, диспатчинги и куери всякие имеют место быть

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

Дело в том, что разговор больше не о стейте как о явлении, а о архитектуре с ним уже не на бегиннер стадии, а когда проект уже на 180 компонентов к примеру. И если делать компоненты в ивент- модели то много вылезает вопросов. Например, дробление стейтов по лейзи модулям создает маразм в отношении их взаимодействия если надо полезть в стейт соседнего модуля, роутер стейт - который демонстрировал Алекс на воркшопе, может решить вопрос контроля роутера, но ведь насколько это заковыристей решение если иногда воркараундом просто можно в компоненте вызвать роутер и прописать там на него кондишен? Роутер же имеет и свой state и data, то есть, неужели вся догруженная сложность описанная выше и есть консистент датафлоу?

Как это вычленять? Как правильно принимать решение относительно неоходимости/чрезмерности оных?

Это и есть работа программиста, за которую платят. Он берет на себя ответственность.

Я предлогаю такую концепцию которую я называю Progressive State Management

Progressive Service Management

Но на самом деле там гибриды

Иначе ангуляр не нужен с его всеми этими input, di и прочими инструментами для передачи контекста

Ну я не согласен )

Feature - Reactive - State

Без базового разбиения все будет превращаться в кашу

Это хорошо работает на green field проектах

а елси проект уже есть то надо смотреть по обстоятельствам

без базового разбиения чего? проекта на фичи?

Ну у меня есть опыт внедрения на позднем этапе, оно тоже сильно помогает

Да

да там на рисунке это не features проекта а features стейтменеджмета