Jaka jest różnica między @ViewChild a @ContentChild?

Kątowa 2 zapewnia @ViewChild, @ViewChildren, @ContentChildi @ContentChildrendekoratorów dla zapytań elementów potomnych danego składnika.

Jaka jest różnica między dwoma pierwszymi a dwoma ostatnimi?

Odpowiem na twoje pytanie za pomocą terminologii Shadow DOM i Light DOM (pochodzi ona z komponentów internetowych, więcej informacji tutaj ). Ogólnie:

• Shadow DOM - to wewnętrzny DOM twojego komponentu, który jest zdefiniowany przez ciebie (jako twórcę komponentu ) i ukryty przed użytkownikiem końcowym. Na przykład:

@Component({
  selector: 'some-component',
  template: `
    <h1>I am Shadow DOM!</h1>
    <h2>Nice to meet you :)</h2>
    <ng-content></ng-content>
  `;
})
class SomeComponent { /* ... */ }

• Lekki DOM - to DOM, który użytkownik końcowy twojego komponentu dostarcza do swojego komponentu. Na przykład:

@Component({
  selector: 'another-component',
  directives: [SomeComponent],
  template: `
    <some-component>
      <h1>Hi! I am Light DOM!</h1>
      <h2>So happy to see you!</h2>
    </some-component>
  `
})
class AnotherComponent { /* ... */ }

Tak więc odpowiedź na twoje pytanie jest dość prosta:

Różnica między @ViewChildreni @ContentChildrenpolega na tym, że @ViewChildrenszukają elementów w Shadow DOM, a @ContentChildrenszukają ich w Light DOM.

Jak sama nazwa wskazuje, @ContentChildi @ContentChildrenzapytań powróci dyrektyw istniejących wewnątrz <ng-content></ng-content>elementu widoku, podczas gdy @ViewChildi @ViewChildrentylko patrzeć na te elementy, które na widok szablonu bezpośrednio.

Ten film wideo od Angular Connect zawiera doskonałe informacje o ViewChildren, ViewChild, ContentChildren i ContentChild https://youtu.be/4YmnbGoh49U

@Component({
  template: `
    <my-widget>
      <comp-a/>
    </my-widget>
`
})
class App {}

@Component({
  selector: 'my-widget',
  template: `<comp-b/>`
})
class MyWidget {}

Z my-widgetperspektywy comp-ajest ContentChildi comp-bjest ViewChild. CompomentChildreni ViewChildrenzwracamy iterowalność, podczas gdy xChild zwraca pojedynczą instancję.

Weźmy przykład: Mamy jeden komponent domowy i jeden komponent potomny, a wewnątrz komponent potomny jeden mały komponent potomny.

<home>
     <child>
           <small-child><small-child>
     </child>
</home>

Teraz możesz pobrać wszystkie elementy potomne w kontekście komponentu domowego za pomocą @viewChildren, ponieważ są one dodawane bezpośrednio w szablonie komponentu domowego. Jednak podczas próby uzyskania dostępu do <small-child>elementu z kontekstu komponentu podrzędnego nie można uzyskać do niego dostępu, ponieważ nie jest on dodawany bezpośrednio w szablonie komponentu podrzędnego. Jest dodawany poprzez projekcję treści do komponentu potomnego według komponentu domowego. W tym miejscu pojawia się @contentChild i możesz go pobrać za pomocą @contentChild.

Różnica występuje, gdy próbujesz uzyskać dostęp do referencji elementów w kontrolerze. Możesz uzyskać dostęp do grab wszystkich elementów, które są bezpośrednio dodawane do szablonu komponentu przez @viewChild. Ale nie można pobrać odniesienia do rzutowanych elementów za pomocą @viewChild Aby uzyskać dostęp do rzutowanego elementu, należy użyć @contentChild.