Как избавиться от проброса 100500 DI-зависимостей в абстрактный компонент? Например, есть

цепочка абстрактных компонентов, каждый из которых наследуется один за другим, и в итоге каждому всё больше нужно пробрасывать зависимости в super(). В итоге не-абстрактный потомок пробрасывает десяток сервисов в super(). Как этого избежать?

Есть статья, но там нормального ответа не дается.

Никак, это порочная проблема иерархии классов. Попробуйте композицию функционала вместо наследования

А как через композицию расширить список методов класса?

Не то, чтобы нет способов, конечно... Нет нормальных способов. Есть ненормальный вариант юзать внутреннее API Angular'а с долбанутыми префиксами типа import privateShit from ΘΘ_PrivateShitDonotFuckingUse_ΘΘ, но меня будут за такое по рукам бить

А как приватный импорт решит проблему что в конструкторе потомка нужны сервисы?

че там за компоненты у вас такие, что надо наследовать

100500 сервисов уже звучит как проблема, да еще и внутри абстрактного класса, еще и в компоненте

Изи решает через setCurrentInjector: import { ɵsetCurrentInjector as setCurrentInjector } from "@angular/core"; export abstract class AbstractFormControlMaterialComponent<T = any> extends AbstractFormControlComponent<T> implements MatFormFieldControl<T> { public ngControl: NgControl; private elementRef: ElementRef; private formBuilder: FormBuilder; constructor(injector: Injector) { super(injector); try { const former = setCurrentInjector(injector); // получаем экзмепляр инжектора const focusMonitor = inject(FocusMonitor); this.elementRef = inject(ElementRef); this.formBuilder = inject(FormBuilder); this.ngControl = inject(NgControl); setCurrentInjector(former); // сеттим инжектор } catch (error) { console.error(error); } } }

а зачем приватный апи для этого, можно просто текущий инжектор взять

Ну, я хочу в отдельном абстрактном компоненте заимплементить ControlValueAccessor, в следующем абстрактном потомке MatFormFieldControl<T>, в другом абстрактном потомке свои абстрактные методы запилить... … и весь этот получившийся суп я хочу в потомке использовать без проброса 100500 зависимостей от сервисов. С формами - получилось (5 абстрактных компонентов над любой формой), но с контролами не очень

Ну, типа это разделение кода по назначению. Прикольно же

разделение в наследовании?

И потом когда надо что-то будет исправить будет очень весело все 5 классов править

Да ну, там же Ангуляр сразу же ошибку выдаст, связанную с конкретным абстрактные классом. Оно уже в проде работает и норм

Я про то что изменения придётся вносить в худшем случае в _пять классов_

Да, ты прав. В случае, если родителю внезапно понадобилась ещё одна зависимость

Сделать новый компонент, наследуемый от существующего?

в доке не уделяют внимание небольшой особенности, интерфейс cva не обязательно компонент должен реализовывать, а любой класс, который заинжектят под цва токеном. Все его методы можно из класса компонента вынести

ОК, и в итоге всё равно же через наследование надо пробрасывать реализованные методы?

Тогда, по сути, то же самое, что у меня сейчас

зачем о.о

Не, а как еще-то. Только implements/extends...

Я джуниор с шестилетним стажем, объясните как тупому

Не наследовать компоненты для наследования логики, а использовать делегирование, или использовать композицию компонентов с помощью директив или других компонентов

если нужно получить логику то выносите её в класс и на следуйте его или инжектите. вот выше тоже самое предлагается.

@Govorin

первые два блока с кодом в RxJs. в 1 вы в переменную записываете Observable а во втором Subscription с учетом того что нейминг переменной подразумевает все таки Observable

а если мне нужны хуки?

хуки не наследуется, вот тут написано. если нужны хуки нужно думать как обойти. описываете ситуацию. https://medium.com/@saniyusuf/part-1-the-case-for-component-inheritance-in-angular-a34fe2a0f7ac

Расскажите кейс Мы в свое время наследование компонентов использовали, замучались выпиливать потом

там сабскрайб лишний. я его уберу.

я Вашу позицию понял, спасибо