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

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 (Árbol de estado único). Sin embargo, en mi opinión, su estado será independencia. Con una tienda, todo está en un solo lugar y las mutaciones son explícitas y se rastrean vs se ensucian en todo y se mantienen localmente por componentes. Además, usted selecciona propiedades específicas de su almacene dentro de su aplicación, para que solo pueda seleccionar los datos que le interesan. Si luego adopta la inmutabilidad en sus reductores devolviendo siempre una matriz por ejemplo y usa Observables, puede hacer uso de ChangeDetectionStrategy OnPush. OnPush te da un buen aumento de rendimiento. Echemos un vistazo a la siguiente figura tomada de los documentos oficiales de Angular :

Como puede ver, una aplicación Angular se construye utilizando una arquitectura de componentes, lo que resulta en 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 Child B es OnPush y Child A es Default y cambias algo dentro Child A, Child B's change detector no se activará ya que no se han cambiado los atributos de entrada. Sin embargo, si cambias algo dentro Child B, Child A se volverá a renderizar ya que tiene el detector de cambios predeterminado.

Tanto sobre el rendimiento y el árbol de estado único. Otro la ventaja de la tienda es que en realidad puede razonar sobre sus cambios de código y estado. Así que la realidad de la mayoría Angular 1.x apps es scope soup. Aquí hay un buen gráfico de una entrada de blog de Lukas Ruebbelke:

La imagen lo demuestra bastante bien. Otro artículo de Tero Parviainen habla sobre cómo mejoró sus aplicaciones Angulares al prohibir ng-controller. Que todo se relaciona con la sopa de alcance y la gestión del estado en constante cambio es difícil. El redux motivación 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, podría causar otro ver para actualizar. En algún momento, ya no entiendes lo que sucede en su aplicación, ya que ha perdido el control sobre el cuándo, por qué y cómo de su estado. Cuando un sistema es opaco y no determinista, es difícil reproducir errores o añadir nuevos función.

Mediante el uso de ngrx/store en realidad puede evitar este problema porque obtendrá un flujo de datos claro en su aplicación.

Dado que ngrx está altamente inspirado por redux, yo diría que los mismos principios principales se aplican:

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

Entonces, en mi opinión, el mayor beneficio es que puede rastrear fácilmente la interacción del usuario y razona sobre los cambios de estado porque despachas acciones y esas conducen siempre a un punto mientras que con los modelos simples tienes que encontrar todas las referencias y ver qué cambia qué y cuándo.

El uso de ngrx/store también le permite usar devtools para ver depurar su contenedor de estado y revertir los cambios. Viajar en el tiempo, supongo, fue una de las principales razones para redux y eso es bastante difícil si estás usando modelos antiguos.

La probabilidad como @ muetzerich ya se mencionó 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, yo diría que no es necesario usar ngrx / store para hacer cualquiera de estas cosas, pero estará atado a restricciones (los tres principios mencionados anteriormente) que proporcionan un patrón común y traen niza beneficio.

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 tratar con varios tipos de datos como estos?

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