NOTA: para simplificar, considere as profundidades dos componentes como:

- Smart (grand)parent level 0
  - dumb child level 1
   ....
    - dumb grandchild level 2
      ....)

Existem várias opções e condições sobre como os componentes inteligentes / geniais / pais / filhos se comunicam e transmitem dados para cima e para baixo em uma cadeia MULTI-NÍVEL (pelo menos três níveis). Gostaríamos de manter nosso componente principal 'inteligente' (grand) como o único componente que tem acesso ao nosso serviço de dados (ou armazenamento atômico / imutável) e isso impulsionará a troca de informações com filhos 'grand' (burros). As opções que vemos são:

Anti-padrão (?): Passe os dados para baixo e para cima na cadeia de componentes através das ligações @ Input / @ Output. Isto é o que alguns chamam de problema de 'propriedades estranhas' ou 'problema de bolhas de eventos personalizados' (por exemplo:aqui eaqui.) problema. Não vá.Antipadrão: acesso de componente inteligente a crianças burras (grand) via @ViewChildren ou @ContentChilden. Isso novamente conecta os filhos e ainda não cria um mecanismo limpo para que os filhos transmitam dados ao componente inteligente.Serviço de mensagens compartilhadas, conforme descrito no livro de receitas angular.ioaqui e um excelente postaqui.?

Agora, no caso de '3', os filhos mudos (grand) devem receber o serviço de mensagens injetado. O que me leva às minhas perguntas:

Q1: Parece intuitivamente estranho para cada um dos filhos "grandões" (grand) ter um serviço de mensagens injetado. A melhor prática é que o serviço de mensagens seja um serviço dedicado para essa família OU faz uma carona no serviço de dados que o avô 'inteligente' é acusado de mencionar acima?

P1A: Além disso, como isso é muito melhor do que adicionar as ligações @ Input / @ Output acima e abaixo da cadeia, se todos os componentes tiverem um serviço injetado? (Vejo o argumento de que o componente "burro" precisa de alguma maneira de obter informações)

P2: E se o avô 'inteligente' estivesse se comunicando com uma loja semelhante ao redux (ngrx para nós)? Mais uma vez, a comunicação com os componentes 'burros' ocorre melhor através de um serviço de mensagens injetadas / dedicadas ou é melhor injetar a loja em cada componente 'burro' ... ou? Observe que a comunicação entre componentes é uma combinação de 'ações' (por exemplo: validação de formulário, botão de desativação, etc.), além de dados (ou seja, adicionar dados a / atualizar loja ou serviço).

Pensamentos muito apreciados!