Открыть список
Как стать автором
Обновить

Комментарии 4

Спасибо за статью, очень много полезной информации. В своих проектах я пришел к использованию специальный классов-DTO для обмена объектами и состоянием между компонентами на одной странице вместо множества Input() и Output().


Понятнее будет показать на примере.


Родительский компонент и код создания класса DTO. Тут компонент, который работает с принимаемым объектом. Иногда даже я вызываю в компонентах не собственные методы, а публичные методы таких классов-провайдеров данных.


Одним из плюсов считаю обленченную возмонжность тестирования класса-провайдера, а также "тонкий" компонент, который лишь отображает поля провайдера и вызывает его методы. Из минусов разве что велосипедостроительство и перформанс приложения — создание объектов для отрисовки и хранение в полях сервисов требует памяти, но это скорее интуитивное мое соображение.


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

Еще не дочитал статью, но уже возник вопрос
Зачем нужен BehaviorSubjectItem? Почему не использовать BehaviorSubject напрямую?

Чтобы не дублировать код "геттера" и "сеттера" переменной состояния

Конечно, можно было использовать просто BehaviorSubject. Но обычно наружу из сервиса стоит выставлять Observable. Так что нужно делать в каждом классе геттер и в нём возвращать subject.asObservable(). Если сервисов много, то получается много однотипного кода. Чтобы избежать бойлерплейта, я завёл класс BehaviorSubjectItem.

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

Информация

Дата основания
1996
Местоположение
Россия
Сайт
www.custis.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре