¿Cuáles son los beneficios de usar store(ngrx) en angular 2

redux angular 5

Question

Estoy trabajando en un proyecto angular 1.xx y estoy pensando en actualizar mi código a angular 2 .

Ahora, en mi proyecto, tengo muchos servicios (de fábrica) para manejar datos que casi mantienen los datos en matrices js (tanto caché como almacenamiento) y procesan estos datos utilizando guiones bajos para manejar matrices.

Encontré muchos ejemplos en angular2 usando ngrx.

¿Cuáles son los beneficios de usar la tienda en comparación con el uso de servicios de datos para manejar datos?

¿Necesito varias tiendas para mi aplicación si tengo varios tipos de datos (stock, pedido, cliente ...)?

¿Cómo puedo estructurar (diseñar) mi aplicación para manejar múltiples tipos de datos como estos?

Answer 1

Aunque su pregunta se basa principalmente en la opinión, puedo darle algunas ideas de por qué ngrx es una buena opción. A pesar de que la gente dice que no es una buena idea tener todo el estado de su aplicación en un solo objeto (Single State Tree). Sin embargo, en mi opinión, su estado estará allí independientemente. Con una tienda, todo es una sola vez y las mutaciones son explícitas y se rastrean frente a las que están sucias y se mantienen localmente por componentes. Además, selecciona propiedades específicas de su tienda dentro de su aplicación, por lo que solo puede seleccionar los datos que le interesan. Si luego acepta la inmutabilidad en sus reductores al devolver siempre una matriz, por ejemplo, y usa Observables, puede hacer uso de ChangeDetectionStrategy OnPush . OnPush te ofrece un buen rendimiento. Echemos un vistazo a la siguiente figura tomada de los docs oficiales de Angular:

Como puede ver, una aplicación angular se crea utilizando una arquitectura de componentes, lo que da como resultado un árbol de componentes. OnPush en un componente significa que solo si los atributos de entrada cambian, la detección de cambio se activará. Por ejemplo, si el Child B es OnPush y el Child A es Default y usted cambia algo dentro del Child A , el detector de cambio del Child B no se activará ya que no ha cambiado ningún atributo de entrada. Sin embargo, si cambia algo dentro del Child B , el Child A se volverá a representar ya que tiene el detector de cambio predeterminado.

Mucho sobre el rendimiento y el árbol de estado único. Otra ventaja de la tienda es que puede razonar sobre su código y los cambios de estado. Entonces, la realidad de la mayoría de las aplicaciones de Angular 1.x es la sopa de alcance . Aquí hay un buen gráfico de una publicación de blog de Lukas Ruebbelke:

La imagen lo demuestra bastante bien. Otro article de Tero Parviainen habla sobre cómo mejoró sus aplicaciones Angulares al prohibir ng-controller . Todo lo relacionado con el alcance de la sopa y la gestión de un estado en constante cambio es difícil. La motivación redux dice lo siguiente ver aquí :

Si un modelo puede actualizar otro modelo, entonces una vista puede actualizar un modelo, que actualiza otro modelo, y esto, a su vez, puede hacer que se actualice otra vista. En algún momento, ya no comprende lo que sucede en su aplicación, ya que ha perdido el control sobre cuándo, por qué y cómo su estado. Cuando un sistema es opaco y no determinista, es difícil reproducir errores o agregar nuevas características.

Al usar ngrx / store, realmente puede solucionar este problema porque obtendrá un flujo de datos claro en su aplicación.

Como ngrx está muy inspirado en redux, diría que se aplican los mismos principios fundamentales :

• Fuente única de verdad
• El estado es de solo lectura
• Los cambios se realizan con funciones puras.

Por lo tanto, en mi opinión, el mayor beneficio es que puede rastrear fácilmente la interacción del usuario y la razón sobre los cambios de estado porque envía acciones y esas siempre conducen a un lugar, mientras que con los modelos simples tiene que encontrar todas las referencias y ver qué cambia qué y qué cuando.

El uso de ngrx / store también le permite usar devtools para ver la depuración de su contenedor de estado y revertir los cambios. El viaje en el tiempo, supongo, fue una de las principales razones para reducir y eso es bastante difícil si está utilizando modelos antiguos simples.

La capacidad de prueba como mencionó @muetzerich ya es también un beneficio de usar ngrx / store. Los reductores son funciones puras y esas funciones son fáciles de probar, porque toman una entrada y simplemente devuelven una salida y no dependen de propiedades fuera de la función y no tienen efectos secundarios, por ejemplo, llamadas http, etc.

Para saltar a la línea de fondo, diría que no es necesario usar ngrx / store para hacer cualquiera de estas cosas, pero estará sujeto a restricciones (los tres principios mencionados anteriormente) que proporcionan un patrón común y brindan beneficios agradables .

A sus preguntas:

¿Necesito varias tiendas para mi aplicación si tengo varios tipos de datos (stock, pedido, cliente ...)?

No, no sugeriría usar varias tiendas.

¿Cómo puedo estructurar (diseñar) mi aplicación para manejar múltiples tipos de datos como estos?

Tal vez esta publicación de blog de Tero Parviainen lo ayude a descubrir cómo diseñar su tienda. Explica cómo diseñar el árbol de estado de la aplicación para una aplicación de ejemplo.

Answer 2

Una buena explicación sobre los beneficios de usar una tienda puede encontrar en la documentation

Estado centralizado e inmutable

Todo el estado de la aplicación relevante existe en una ubicación. Esto hace que sea más fácil rastrear problemas, ya que una instantánea del estado en el momento de un error puede proporcionar información importante y facilitar la recreación de problemas. Esto también hace que los problemas notoriamente difíciles, como deshacer / rehacer, sean triviales en el contexto de una aplicación de la Tienda y permite herramientas poderosas.

Actuación

Dado que el estado está centralizado en la parte superior de su aplicación, las actualizaciones de datos pueden fluir hacia abajo a través de sus componentes dependiendo de las secciones de la tienda. Angular 2 está diseñado para optimizar en una disposición de flujo de datos de este tipo, y puede desactivar la detección de cambios en los casos en que los componentes se basan en observables que no han emitido nuevos valores. En una solución de tienda óptima, esta será la gran mayoría de sus componentes.

Testabilidad

Todas las actualizaciones de estado se manejan en reductores, que son funciones puras. Las funciones puras son extremadamente simples de probar, ya que es simplemente ingresar, afirmar contra la salida. Esto permite probar los aspectos más cruciales de su aplicación sin simulacros, espías u otros trucos que pueden hacer que las pruebas sean complejas y propensas a errores.

Múltiples tiendas?

IMO usa una tienda y agrega tus tipos de datos como propiedades en tu tienda.

Answer 3

ngrx.store hace lo que hará un componente / servicio bien diseñado, con beneficios adicionales. Hasta ahora, y estoy comenzando a trabajar en cómo esto se combina, esto es lo que he encontrado:

Es realmente fácil obtener un desorden imposible de mantener con los servicios y componentes. Si tiene acciones en cascada, interacciones de datos complejas y llamadas a ubicaciones remotas, termina estructurando un servicio que es casi idéntico al arreglo de almacén-reductor de acciones en ngrx. Pequeñas funciones puras, observables, etc. ngrx ya lo tiene, ¿por qué no usarlo y aprovechar el pensamiento y los patrones que representa?

Si fuerza / fomenta el pensamiento en pequeñas funciones comprobables. Diseñar un reductor o reductores múltiples para un componente moderadamente complejo impone una disciplina que eliminará muchas de las dificultades que consumen horas. Nada se traga horas como rastrear una condición de carrera casi multiproceso derivada de la cola de devolución de llamada. Estoy seguro de que esto puede suceder con los reductores, pero simplifica el acceso a la secuencia de llamadas y al estado para la depuración.

El patrón Angular2 se vuelve más fácil. Plantillas con la lógica de visualización, componentes como un lugar de reunión de todos los bits y piezas que necesita la plantilla. Los servicios se vuelven más simples ya que simplemente hacen llamadas remotas o manejan el io para obtener datos de donde sea que provengan. Luego, las acciones y reductores para mantener y cambiar el estado, lo que provoca que todas las otras partes respondan al nuevo estado. Descubrí que con el patrón de componente / servicio, cualquiera de los dos comenzaría a ser grande y complicado, con el efecto secundario de que se volvería extremadamente difícil de depurar. Mis servicios terminaban almacenando el estado y haciendo los datos io.

Observables Todo se puede observar en rxjs.store, y esa es la base para una aplicación receptiva. Estructurar el estado de la aplicación como observable es a veces un poco arcano o no muy sencillo, pero descubrirlo y hacerlo bien paga grandes dividendos más adelante.

Lo único negativo que puedo ver es que los reductores se vuelven extraordinariamente grandes muy rápidamente. Parece que hay muchas situaciones en las que se repite y se repite el mismo código con diferentes nombres. Mi cerebro grita ''función con parámetros'', pero no funciona de esa manera. Por otro lado, aquí es donde la estructura y el estado de la aplicación se expresan en todos sus detalles, por lo que seguramente habrá muchos allí. Y cuando algo sale mal, como inevitablemente sucederá, tener una función pura como la fuente del problema hace que sea más fácil localizarlo y solucionarlo.