main.component
state$: Observable<T>;

ngOnInit() {
 this.state$ = this.store.pipe(select(feature))
}

<ng-container *ngIf="state$ async as state">
    
</ng-container>

а если я не могу сразу передавать сырые данные( то что получил по апи) в компоненты, мне их надо предобработать. Где эту логику хранить в сервисе или в селектах?
Логика с этой “предобработкой” занимает ну где-то под 50 строк кода для каждого компонента

1. Эта логика одинакова?
2. Что за именно логика?

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

В первых двух случаях помогло в третьем нет.

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

Тогда зачем Ngrx?

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

Помогите пожалуйста, не могу разобраться с WebWorker в Angular, делал все по документации, но сообщения с воркера не приходит. Создавал воркер командой ng g web-worker app

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

я хочу избавиться от необходимости передавать из компнента в компонет эти данные, а также эмитить эти события наверх до самого main.component т.к. весь этот drag&drop работает в рамках него.

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

Коллеги, кто использовал ngrx/data? Облегчает жизнь?

так в реакте же есть подход на смарт и дами компоненты

Тут также, и не нужно прям в корень компоненты все прокидывать

А то получаеться у вас 1 контейнер на 3000 дамми

ну со стороны реализации drag&drop так и получается

для остальных фич логика хранится в соответствующих компонентах

В общем спасибо) буду че-нить пробовать

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

в каких моделях?