route - Angular 2+/ 4/5/6/7: comunicación de componentes inteligente, tonta y profundamente anidada

meta tags angular 6

Question

NOTA: por simplicidad 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 smart / grand / parent / child se comunican y pasan los datos hacia arriba y hacia abajo en una cadena de niveles múltiples (al menos 3 niveles). Nos gustaría mantener nuestro componente principal "inteligente" (gran) como el único componente que tiene acceso a nuestro servicio de datos (o tienda atómica / inmutable) y que impulsará el intercambio de información con los niños "tontos" (grandes). Las opciones que vemos son:

1. Anti-patrón (?) : Pase los datos hacia abajo y hacia arriba en la cadena de componentes a través de @ Input / @ Output bindings. Esto es a lo que algunos se refieren como el problema de "propiedades extrañas" o "problema de propagación de eventos personalizados" (por ejemplo: here y here ). No vayas.
2. Anti-patrón: acceso de componentes inteligentes a niños tontos (grandes) a través de @ViewChildren o @ContentChilden. De nuevo, esto cablea a los niños y aún no crea un mecanismo limpio para que los (grandes) niños pasen los datos al componente inteligente.
3. Servicio de mensajes compartidos como se describe en el libro de cocina angular.io here y una excelente publicación here .
4. ?

Ahora, en el caso de ''3'', los niños mudos (grandes) deben recibir la inyección del servicio de mensajes. Lo que me lleva a mis preguntas:

P1: Parece intuitivamente extraño que cada uno de los niños "tontos" (grandes) tenga un servicio de mensajes inyectado. ¿La mejor práctica para que el servicio de mensajes sea un servicio dedicado para esta familia O se recarga en el servicio de datos con el que se acusa al abuelo "inteligente" mencionado anteriormente?

P1A: Además, ¿cómo es esto mucho mejor que agregar enlaces @ Input / @ Output en toda 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é sucede si el gran padre "inteligente" se comunicaba con una tienda similar a Redux (ngrx para nosotros)? Una vez más, la comunicación con los componentes ''tontos'' ocurre 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 / actualización de tienda o servicio).

¡Pensamientos muy apreciados!

Answer 1

¿Por qué es # 1 un anti-patrón? El componente abuelo posee los datos y los pasa a los componentes secundarios tontos a través de los parámetros @Input. Los componentes secundarios tontos simplemente invocan devoluciones de llamada cuando ocurre un evento (a través de los emisores de eventos @Output), lo que hace que el componente abuelo manipule los datos. Me parece limpio.

Edición: veo su punto acerca de pasar repetidamente valores como un controlador de envío a través de muchas capas intermedias. Tal vez se pueda crear una estructura anidada que represente su árbol de componentes en el componente principal. Luego, a cada componente se les pueden pasar las propiedades que necesita, más un objeto para pasar al siguiente componente. Entonces, cada componente solo conoce el que está debajo:

// Parent component builds this object (or gets a service to do it)
viewModelForChildComponent: {
property1NeededForChildComponent,
property2NeededForChildComponent,
viewModelForGrandChildComponent: {
property1NeededForGrandChildComponent,
property2NeededForGrandChildComponent,
viewModelForGrandGrandChildComponent: {
property1NeededForGrandGrandChildComponent,
submitHandlerNeededForGrandGrandChildComponent
}
}
}

Answer 2

(ACTUALIZACIÓN: 02-07-2019: esta publicación se estaba actualizando: se agregó el patrón ''store / ngrx'')

Entonces, después de analizar esto más a fondo, cuando se trata de la mejor manera de comunicarse a través de una cadena de componentes anidada, parece que en realidad solo hay dos opciones: una negociación entre los Fausto:

YA SEA

• pase los enlaces @ Entrada / @ Salida hacia arriba, hacia abajo y a lo largo de la cadena de componentes anidada (es decir, resuelva los problemas de ''burbujeo de eventos personalizados'' o ''propiedades extrañas'')

O

• Use un servicio de mensajería / suscripción para comunicarse entre esta familia de componentes ( here gran descripción) e inyecte ese servicio para cada componente de la cadena.

O:

• El patrón de almacenamiento reactivo (por ejemplo, ''ngrx'') es otra opción. Tenga en cuenta, IMO, las nociones de componentes inteligentes y tontos todavía se aplican. A saber, los componentes tontos nunca acceden directamente a la tienda. Una vez más, los componentes inteligentes son la parte principal para obtener datos a través de la tienda.

Personalmente, soy un partidario de utilizar componentes inteligentes y de presentación ("tontos"). La adición de una ''tienda'' también debe hacerse de manera selectiva, ya que aumenta significativamente los costos del proceso, desde la arquitectura, los patrones de implementación consistentes, el desarrollo y el mantenimiento hasta la incorporación de nuevo personal. Nominalmente, un componente ''tonto'' solo necesita @Inputs y @Outputs y eso es todo. No importa cuán profundo o superficial sea en un árbol de componentes, ese es el problema de las aplicaciones. De hecho, no importa qué aplicación la use en primer lugar. Mientras tanto, un componente de profundidad no es muy tonto o transportable si se le inyecta un servicio específico de aplicación. Por cierto, el componente ''inteligente'' de contraparte está realmente proporcionando servicios intermediarios (a través de un servicio @Injectable de primera clase o una tienda similar a Redux) a cualquier componente tonto en su árbol genealógico que lo necesite. El componente inteligente tampoco se preocupa por los componentes más allá de los @Inputs inmediatos de su hijo, siempre y cuando los nietos señalen una acción de servicio / tienda que se debe realizar (de nuevo a través de la cadena @ Input / @ Output). De esta manera, un componente inteligente también se puede transportar a través de las líneas de aplicación.

Debido a esto, la negociación de Faustian, IMO, se inclina hacia la utilización de una cadena de entrada / entrada con todos los problemas mencionados que trae consigo. Dicho esto, estoy atento a esto y doy la bienvenida a alternativas limpias y desacopladas si alguien sabe de alguna.

Answer 3

Los enlaces de entrada () y de salida () también son una forma perfectamente legítima de manejar esto. Deje que el componente inteligente maneje la lógica de generar los valores y luego use Input () y Output () para simplemente pasar y recibir los valores a lo largo de la cadena de componentes.

Por supuesto, esto apunta a una de las desventajas del enfoque inteligente / vista: más archivos; más repetitivo. Es por eso que no abogaría por un enfoque único que sea único para todos. Más bien, elija un enfoque que tenga sentido en su contexto actual (tanto para la aplicación como para su organización).