NOTA: para simplificar, considere las profundidades de los componentes como:

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

Hay varias opciones y condiciones sobre cómo los componentes inteligentes / grandiosos / padres / hijos se comunican y transmiten datos hacia arriba y hacia abajo en una cadena de MÚLTIPLES NIVELES (al menos 3 niveles). Nos gustaría mantener nuestro componente padre 'inteligente' (gran) como el único componente que tiene acceso a nuestro servicio de datos (o tienda atómica / inmutable) e impulsará el intercambio de información con niños 'tontos' (grandes). Las opciones que vemos son:

Anti-patrón (?): Pase datos hacia arriba y hacia abajo en la cadena de componentes a través de enlaces @ Input / @ Output. Esto es a lo que algunos se refieren como el problema de 'propiedades extrañas' o 'problema de burbujeo de eventos personalizados' (por ejemplo:aquí yaquí.) problema. No vayas.Anti-patrón: acceso de componentes inteligentes a niños tontos (grand) a través de @ViewChildren o @ContentChilden. Esto nuevamente conecta a los niños y aún no crea un mecanismo limpio para que los (grandes) niños pasen los datos al componente inteligente.Servicio de mensajes compartidos como se describe en el libro de cocina angular.ioaquí y una excelente publicaciónaquí.?

Ahora en el caso de '3', los niños tontos (grand) deben tener el servicio de mensajes inyectado. Lo que me lleva a mis preguntas:

P1: Parece intuitivamente extraño que a cada uno de los niños 'tontos' (grandiosos) se les inyecte un servicio de mensajes. ¿Es la mejor práctica que el servicio de mensajes sea un servicio dedicado para esta familia O se apoya en el servicio de datos del que se encarga al abuelo 'inteligente' mencionado anteriormente?

Q1A: Además, ¿cómo es esto mucho mejor que agregar enlaces @ Input / @ Output arriba y abajo de la cadena si todos los componentes tendrán un servicio inyectado? (Veo el argumento de que el componente 'tonto' necesita ALGUNA forma de obtener información)

P2: ¿Qué pasaría si el abuelo 'inteligente' se comunicara con una tienda tipo redux (ngrx para nosotros)? Una vez más, ¿la comunicación con los componentes 'tontos' se realiza mejor a través de un servicio de mensajes inyectados / dedicados o es mejor inyectar la tienda en cada componente 'tonto' ... o? Tenga en cuenta que la comunicación entre componentes es una combinación de 'acciones' (por ejemplo: validación de formulario, botón de desactivación, etc.) además de datos (es decir, agregar datos a / actualizar la tienda o servicio).

Pensamientos muy apreciados!