Плюсы такого подхода через DI перечислены верно, в проекте он используется регулярно. Что касается сравнения с ngIf, то в статье есть пример подхода с ngIf, ngSwith и ngTemplateOutlet, в целом это рабочие решения, но тогда логика определения бренда переходит в общий компонент, что конечно его усложняет и затрудняет масштабирование.
Хороший вопрос. Получение компонента как зависимости дает возможность динамического управления его состоянием, поведением и отображением внутри вашего приложения. Это позволяет создавать гибкие, масштабируемые и адаптивные компоненты, которые могут быть переиспользованы и настраиваемы в различных сценариях.
К примеру, в общем компоненте можно создать экземпляр компонента бренда, отобразить его в шаблоне, при этом первый компонент будет абстрагирован об логики брендов и легко переиспользован.
Да, при сборке приложения для сервера получается 1 большой бандл. Хотя это не выглядит большой проблемой, тк он не передаётся куда то по сети в отличии от клиентского.
Плюсы такого подхода через DI перечислены верно, в проекте он используется регулярно.
Что касается сравнения с ngIf, то в статье есть пример подхода с ngIf, ngSwith и ngTemplateOutlet, в целом это рабочие решения, но тогда логика определения бренда переходит в общий компонент, что конечно его усложняет и затрудняет масштабирование.
Хороший вопрос. Получение компонента как зависимости дает возможность динамического управления его состоянием, поведением и отображением внутри вашего приложения. Это позволяет создавать гибкие, масштабируемые и адаптивные компоненты, которые могут быть переиспользованы и настраиваемы в различных сценариях.
К примеру, в общем компоненте можно создать экземпляр компонента бренда, отобразить его в шаблоне, при этом первый компонент будет абстрагирован об логики брендов и легко переиспользован.
Да, при сборке приложения для сервера получается 1 большой бандл. Хотя это не выглядит большой проблемой, тк он не передаётся куда то по сети в отличии от клиентского.