Комментарии 4
Спасибо за статью, очень много полезной информации. В своих проектах я пришел к использованию специальный классов-DTO для обмена объектами и состоянием между компонентами на одной странице вместо множества Input() и Output().
Понятнее будет показать на примере.
Родительский компонент и код создания класса DTO. Тут компонент, который работает с принимаемым объектом. Иногда даже я вызываю в компонентах не собственные методы, а публичные методы таких классов-провайдеров данных.
Одним из плюсов считаю обленченную возмонжность тестирования класса-провайдера, а также "тонкий" компонент, который лишь отображает поля провайдера и вызывает его методы. Из минусов разве что велосипедостроительство и перформанс приложения — создание объектов для отрисовки и хранение в полях сервисов требует памяти, но это скорее интуитивное мое соображение.
Я не фронтендер, поэтому буду благодарен, если автор статьи или любой другой фронтендер посмотрит мой подход и либо похвалит, либо распишет минусы, которые не вижу я
Зачем нужен BehaviorSubjectItem? Почему не использовать BehaviorSubject напрямую?
Чтобы не дублировать код "геттера" и "сеттера" переменной состояния
Конечно, можно было использовать просто BehaviorSubject. Но обычно наружу из сервиса стоит выставлять Observable. Так что нужно делать в каждом классе геттер и в нём возвращать subject.asObservable(). Если сервисов много, то получается много однотипного кода. Чтобы избежать бойлерплейта, я завёл класс BehaviorSubjectItem.
Как управлять состоянием в Angular по мере роста приложения