Статический @Просмотр детей

#angular11 #viewchild

Вопрос:

У меня возникла ситуация, когда я должен был заменить

 @ViewChild(Foo, { static: true }) foo!: Foo;  

с версией, которая получает несколько Foo в списке.

Ожидаемым решением является

 @ViewChildren(Foo, { static: true }) foos!: QueryListlt;Foogt;;  

но @ViewChildren не поддерживает static .

Есть ли здесь какая-нибудь работа?

Пример использования заключается в том, что у меня есть что-то вроде этого:

 @ViewChild(Foo, { static: true }) foo!: Foo;  ngOnInit(): void {  onFooInit(this.foo); }  ngAfterViewInit(): void {  afterViewFooInit(this.foo); }  

и мне нужно, чтобы это стало

 @ViewChildren(Foo, { static: true }) foos!: QueryListlt;Foogt;;  ngOnInit(): void {  this.foos.forEach(onFooInit); }  ngAfterViewInit(): void {  this.foos.forEach(afterViewFooInit); }  

где onFooInit и afterViewFooInit находятся функции библиотеки черного ящика , в документации которых указано, что их следует вызывать, ngOnInit и ngAfterViewInit , соответственно, указано, что { static: true } для этого необходимо. (Я проверил это, и да, есть ошибки и без { static: true } этого .)

Я попробовал использовать некоторые хакерские приемы @ViewChild(Foo, { static: true }) set foo(foo: Foo) { this.foos.push(foo); } , которые, что неудивительно, ни к чему не привели, и я попытался создать свой собственный декоратор, который внутренне вызывал ViewChild каждое совпадение селектора, но я не смог заставить его работать. Одна вещь, которую я знаю, я мог бы сделать, это просто использовать ViewChild каждую отдельную вещь, которую я хочу включить в список, а затем жестко закодировать фактическое создание списка из них, но я хочу повторно использовать этот код в нескольких компонентах, что очень быстро станет болезненным.

Затем я понял, что это действительно должна быть директива, но ElementRef в директиве те же проблемы, она не определена ngOnInit (я думаю, она не статична). Альтернативой директиве является компонент упаковки, но тогда мне приходится беспокоиться обо всех вводимых данных, что является огромной болью. Хотя, вероятно, лучше, чем жестко закодированный полиморфный список.

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