Картина маслом:

• Общий стейт для модуля

• Фасады для каждого компонента

• Компоненты инжектят свои Фасады

• Фасад выполняет "грязную" работу компонента

• Через фасад компонент получает данные, изменяет стейт, исполняет АПИ запросы

ИСХОДНЫЕ ДАННЫЕ:

• Страница PANEL с данными юзера и компонент PAYMENT для работы с payment-card:

• резолвер данных по роутингу

• главный компонент

• компонент по роутингу

PanelState для модуля (планируется до 5 компонентов)

• BehaviorSubject'ы для списков, объектов, др. переменных

• Содержит get / set для всех BehaviorSubject'ов

1. Забираю начальные данные

2. Сохраняю в PANELSTATE

3. Все равно возвращаю резолв в роут

Через PanelFacade

• вытаскиваем данные явно (если надо) 

• checkCardError();

PaymentFacade (part 1)

В DI фасада находятся:

• Общий стейт

• Апи сервис

• Другие фасады...

 

PaymentFacade (part 2)

...В фасаде находятся:

I. Селекторы объектов 

II. Другие фасады

III. Изменение PanelState

IV. Бизнес логика 

 

В компоненте находятся:

I. DI PaymentFacade - фасад этого компонента

II. Селектим все данные

III. Вся бизнес логика передается в фасад

 

 

PaymentComponent

PaymentComponent

• Через async pipe берем user

• Выполняем методы

Итого:

• Существует общий стейт для все переменных$

• Фасады для каждого компонента

• Фасад инжектит только API и STATE сервисы

• Компоненты инжектят свои Фасады

• Компоненты НЕ инжектят API или STATE сервисы

Мои предположения:

• Стоит придерживаться фасадов, т.к. компонент в таком случае - чистый presentation layer

• Стоит разделять сервисы на API, STATE, FACADE сервисы, для понимания функций каждого

 

Плюсы такого подхода:

• Все изменения происходят в Фасаде (easy to debug)

• Разделение логики по сервисам

• Проще маинтейнить

• Появляется возможность держаться RXJS подхода

• Легко начать использовать

дает возможность перейти на any reactive state manager framework ngrx / ngxs / akita etc.