Представим пример. Есть модуль с компонентами для конкретного стиля, скажем - Material Design. Создадим компонент "CRUD Таблица", который содержит дизайнерские компоненты: таблицу, кнопки, модальные окна и т.д. Затем создадим "CRUD REST Component", который содержит "CRUD Таблицу" и управляет ею с помощью конкретного сервиса с заранее заданными урлами для обращения к rest-серверу.
"CRUD REST Component"
- rest servise (CRUD операции с сервером)
- "CRUD Таблица"
-- компоненты в определённом стиле: кнопки, формы, модальные окна
Но вдруг возникает необходимость использовать "CRUD REST Component" в другом проекте с другими стилистическими компонентами, при этом логика работы с "CRUD Таблицей", модальными окнами и т.д. должны повторяться.
Если бы это был императив, можно было бы решить задачку с помощью интерфейсов или наследования. Но как решение выглядит с Ангуляровскими шаблонами?
На компонентах толком никак.
Выносите сложную логику в сервисы (CRUD REST Service и т.д) и инжектите эти сервисы на локальные компоненты.
Вообще инкапсулирование шаблонов и стилей в отдельные пакеты очень сильно ограничивает при решении реальных задач.
Sasha Novik, речь ведь идёт не о сложной логике, которая конечно выносится в сервис, а о часто повторяющихся действиях между компонентами представления. Например, модальное окно можно показать и спрятать, внутрь положить контент и кнопки с возвращаемым результатом. Как бы такие окна не выглядели: в стиле материал, бутстрапа, чего-то оригинального - всё это разукрашивание не должно повлиять на логику взаимодействия с таким компонентом. Тогда я смогу строить составные компоненты, которые перерисовываются в нужном стиле, стоит лишь поменять оформление базовых компонентов.
Есть большая вероятность, что придётся отвечать самому, ибо наши адепты кодинга верно поклоняются богу копипаста.
Из доступных решений первой приходит идея конфигурировать корневой модуль компонента. C этим подходом сразу виднеются проблемы: классы компонентов приходится называть одним именем (это ещё ладно) и производить импорт приходится не из npm зависимостей, а с использованием алиаса пути в корень проекта (вот это уже злостное нарушение модульности).
Следом приходит более работоспособное решение: создать абстрактный модуль, который содержит интерфейсы компонентов и импортируется зависящими компонентами. При этом сам модуль нужно настраивать в модуле верхнего уровня конкретной реализацией.
Хотелось бы увидеть решение, похожее на подмену сервисов:
{provide: ServiceName, useClass: FakeServiceName}
Средний
Средний
