angular - ¿Qué tan "tonto" deberían ser los componentes estúpidos?

redux angular 6

Question

Estoy construyendo mi aplicación Redux (NgRx) con componentes inteligentes / volcado, pero estoy luchando para decidir qué tan tontos deberían ser los componentes tontos ...

Por ejemplo, tengo un componente inteligente ( posts ) que tiene un componente tonto ( post-list ), que contiene componentes tontos ( post ). Hasta aquí todo se ve bien.

Para mostrar algunos botones, necesito saber si el usuario es admin o no, y tendría que pasar el admin la propiedad desde las posts hasta la post .

¿Puedo conectar la post componente tonto a la tienda y obtenerla directamente del componente tonto? ¿O el componente en este caso es más tonto? Se vería algo como esto:

 private admin$: Observable<boolean>;
constructor(private store: Store<AppState>){
this.admin$ = this.store.let(isAdmin());
}

Creo que esto ahorraría mucha redundancia. ¿Es esta buena o mala práctica?

Answer 1

Esta pregunta se aplica a cualquier marco de trabajo del lado del cliente, incluyendo React / Flux, así como a las aplicaciones heredadas Angular 1.x (generalmente a través de algo como https://github.com/angular-redux/ng-redux ) y como con muchas cosas, el La respuesta es que depende de sus casos de uso.

Sin embargo, has hecho dos preguntas. Cuán tontos deberían ser los componentes estúpidos y la mejor manera de determinar si un componente debería ser tonto en primer lugar.

Pregunta 1: Para la mejor manera de determinar si un componente debe ser tonto en primer lugar:

En su caso específico, haría la pregunta: ¿Los componentes de la lista de publicaciones o publicaciones se usarán fuera de las publicaciones? Es así, haga del "nivel" más alto el componente inteligente (también llamado contenedor). Por ejemplo, si Publicar solo se usará dentro de la Lista de publicaciones, pero la Lista de publicaciones se puede usar fuera de las publicaciones, la Lista de publicaciones debe ser el componente inteligente que le permita "incluirlo" en otros componentes más fácilmente.

Eso ejemplifica un enfoque general sin embargo. Pregunte si es probable que un componente tonto exista arriba o como un hermano para su componente inteligente, y si es así, promuévalo y, de no ser así, déjelo como un componente tonto.

Pregunta 2: ¿Qué tan "tonto" debería ser un componente tonto?

Un componente tonto necesita pasar cualquier cosa que cambie, y como una mejor práctica, los métodos para llamar a cualquier evento que pueda ocurrir en función de la acción del usuario .

Por ejemplo: si el texto, las imágenes o los medios se basan en cambios en el estado de la aplicación, estos datos se deben pasar al componente. Y si existen botones, enlaces, formularios u otros elementos en los que se puede hacer clic, al pasar al menos retrollamadas / métodos opcionales para invocarlos se proporcionará a los usuarios de su componente (incluso si se trata de usted) flexibilidad futura a medida que crecen los requisitos de la aplicación.

Answer 2

Me parecería "tonto" como reutilizable en un contexto diferente.

Dumb solo sería interesante para sus padres.

Un mantra me repito a mí mismo usando angular 2. Si se está volviendo complicado y confuso, reconsidere mi estrategia.

¿Qué pasa con otro nivel de componentes? el modo de administrador es un niño, el no administrador es otro. Esos componentes secundarios podrían obtener sus datos a través de Input y emitir a través de Output.

Answer 3

Los componentes tontos deben ser componentes de presentación sin ninguna lógica.

Según Dan Abramov del equipo de reacción, los componentes tontos coinciden con los siguientes criterios:

• Están preocupados por cómo se ven las cosas.
• Puede contener tanto componentes de presentación como de contenedor ** en su interior y, por lo general, tiene marcas propias y estilos de DOM.
• A menudo permite la contención a través de this.props.children.
• No tener dependencias en el resto de la aplicación, como acciones de Flux o tiendas.
• No especifique cómo se cargan o mutan los datos.
• Reciba datos y devoluciones de llamadas exclusivamente a través de accesorios.
• Rara vez tienen su propio estado (cuando lo hacen, es el estado de la interfaz de usuario en lugar de datos).
• Se escriben como componentes funcionales a menos que necesiten estados, enlaces de ciclo de vida u optimizaciones de rendimiento.
• Ejemplos: página, barra lateral, historia, información de usuario, lista.

En angular

Deberían simplemente mostrar la información y manejar eventos por flujos de entrada y salida.

Así que mi recomendación es verificar la aplicación de ejemplo ngrx en smart y tonto: https://github.com/ngrx/example-app

También puedes ver cómo hice la implementación de lo inteligente y lo tonto en el juego. https://github.com/wizardnet972/tic-tac-toe

Nota: los componentes del contenedor también son reutilizables. Si un componente es o no un componente de presentación o un componente contenedor es un detalle de implementación.

Los componentes de presentación reciben datos a través de @Input () y comunican eventos a través de @Output () pero generalmente no mantienen un estado interno propio. Todas las decisiones se delegan en componentes ''contenedor'' o ''inteligentes'' antes de que las actualizaciones de datos vuelvan a fluir.

Espero que sea útil.

Answer 4

Supongo que necesita cambiar la estructura de sus componentes como la imagen: - Smart_VS_Dumb