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

+

Я все хочу потыкать ngrx, но банально спотыкаюсь что он никакие проблемы в итоге не решает, а если решает то это я тупой и в итоге все решается rxОМ

ну это по сути набор оттестированных инструментов с общедоступной докой.
т.е. фактически ngrx и подобные это протокол

Это больше про flux же

вот отлично! сейчас кейсов подгоню. между тем моя ситуация такова что я вынужденно вписался в эту redux тему поскольку в проекте буквально каждая фича на ней.

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

да не. наоборот. я сижу на аките, которая лишь эмулирует flux местами. но в целом пофигу

а можно взглянуть на пример простенького сервиса?

для локальных данных есть практика просто создавать раздел в глобальном стейте с именем типа user-5345342, а потом вырезать его.
т.е. uuid делать типа

Не совсем простенький, но все же. Трекер изменений для айтемов таблицы, похожий по принципу на formControl, можно получить текущее состояние, дифф, оригинальное состояние. Создаётся вместе с компонентом, умирает тоже. В процессе сам регистрируется в гардах чтобы не закрылась страничка с несохраненными изменениями

первый раз такое вижу. у нас архитектура построена примерно следующим образом: проект поделен на фичи, каждая из которых работает с набором сущностей. к примеру фича "таски". и каждая фича имеет свой стэйт, который обрабатывает CRUD операции над сущностями. типа ТаскСтейт у него есть таски, фильтр, что то для пагинации и прочее. и компоненты восновном глупые - дергают события ("установить фильтр",  "запросить таски", "создать таск" итд)

можно еще запилить сервис, который будет имитировать ngxs :)

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

сабджекты приватные внутри сервиса?

зачем ?

регистрируется в гардах это как о.О
и зачем. canDeactivate имеет доступ к компоненту, который закрывается

А как при сборке нормально понять, что конкретно не нравится?

Ну так-то да, часть внешнего api - пайпы от состояния

Это вообще не информативно