Комментарии 4
И в общем компоненте, через DI получаем компонент бренда
А зачем нам компонент получать как зависимость, что с ним дальше делать?
Хороший вопрос. Получение компонента как зависимости дает возможность динамического управления его состоянием, поведением и отображением внутри вашего приложения. Это позволяет создавать гибкие, масштабируемые и адаптивные компоненты, которые могут быть переиспользованы и настраиваемы в различных сценариях.
К примеру, в общем компоненте можно создать экземпляр компонента бренда, отобразить его в шаблоне, при этом первый компонент будет абстрагирован об логики брендов и легко переиспользован.
Имхо, не хватает сравнения с обычным ngIf, который будет отрисовывать либо компонентА, либо компонентБ.
Я вот вижу плюсы, что не будет размазывания логики по сервисам и резолверам, не будет работы с компонентами в компоненте (а только в шаблоне). Можно будет сделать разные инпуты в компоненты разных брендов.
Сейчас это выглядит очень шатко и применимо в каком то ограниченном количестве кейсов
Плюсы такого подхода через DI перечислены верно, в проекте он используется регулярно.
Что касается сравнения с ngIf, то в статье есть пример подхода с ngIf, ngSwith и ngTemplateOutlet, в целом это рабочие решения, но тогда логика определения бренда переходит в общий компонент, что конечно его усложняет и затрудняет масштабирование.
Мультибрендинг сайта на Angular