Angular 6: por qué usar @ ngrx / store en lugar de la inyección de servicios

Recientemente estoy aprendiendo Angular 6 con @ ngrx / store, mientras que uno de los tutoriales es usar @ ngrx / store para la administración del estado, sin embargo, no entiendo el beneficio de usar @ ngrx / store detrás de escena.

Por ejemplo, para una simple acción de inicio de sesión y registro, previamente usando el servicio (llamémoslo AuthService) podríamos usarlo para llamar a la API de backend, almacenar "userInfo" o "token" en AuthService, redirigir al usuario a "HOME" page y podemos inyectar AuthService en cualquier componente donde necesitemos obtener el userInfo usando DI, que simplemente ese archivo AuthService maneja todo .

Ahora, si estamos usando @ ngrx / store, necesitamos definir la Acción / Estado / Reductor / Efectos / Selector que probablemente necesite escribir en 4 o 5 archivos para manejar la acción o el evento anterior, entonces a veces todavía necesitamos llamar a la API de backend usando el servicio, que parece mucho más complicado y redundante ...

En algún otro escenario, incluso veo que alguna página usa @ ngrx / store para almacenar el objeto o la lista de objetos como datos de cuadrícula. , ¿ es eso para algún tipo de uso de almacenamiento en memoria?

Entonces, volviendo a la pregunta, ¿por qué estamos usando @ ngrx / store sobre la tienda de registro de servicio aquí en el proyecto Angular? Sé que es para uso de " GESTIÓN DEL ESTADO ", pero ¿qué es exactamente "GESTIÓN DEL ESTADO"? ¿Es algo así como el registro de transacciones y cuándo lo necesitamos? ¿Por qué lo administraríamos desde el principio? ¡No dude en compartir su sugerencia o experiencia en el área @ ngrx / store!

Creo que deberías leer esas dos publicaciones sobre la tienda Ngrx:

• Capas de servicios angulares: Redux, RxJs y Ngrx Store: ¿cuándo usar una tienda y por qué?
• Tienda Ngrx: una guía de arquitectura

Si el primero explica los principales problemas resueltos por Ngrx Store, también cita esta declaración del React How-To "que parece aplicarse igualmente a Flux original, Redux, Ngrx Store o cualquier solución de tienda en general":

Sabrá cuándo necesita Flux. Si no está seguro de si lo necesita, no lo necesita.

Para mí, la tienda Ngrx resuelve múltiples problemas. Por ejemplo, cuando tiene que lidiar con observables y cuando la responsabilidad de algunos datos observables se comparte entre diferentes componentes. En este caso, las acciones de almacenamiento y el reductor aseguran que las modificaciones de datos siempre se realizarán "de la manera correcta".

También proporciona una solución confiable para el almacenamiento en caché de solicitudes http. Podrá almacenar las solicitudes y sus respuestas, de modo que pueda verificar que la solicitud que está realizando aún no tiene una respuesta almacenada.

La segunda publicación trata sobre lo que hizo que aparecieran tales soluciones en el mundo React con el problema del contador de mensajes no leídos de Facebook.

Con respecto a su solución de almacenamiento de datos no observables en servicios. Funciona bien cuando se trata de datos constantes. Pero cuando varios componentes tengan que actualizar estos datos, probablemente encontrará problemas de detección de cambios y problemas de actualización inadecuados, que podría resolver con:

• patrón de observador con privado Sujeto público Observable y función siguiente
• Tienda Ngrx

También hay una tercera opción, tener datos en servicio y usar el servicio directamente en html, por ejemplo *ngFor="let item of userService.users". Por lo tanto, cuando actualiza userService.usersen servicio después de agregar o actualizar, la acción se representa automáticamente en html, no es necesario ningún observable, evento o almacenamiento.

Si los datos de su aplicación se utilizan en varios componentes, se requiere algún tipo de servicio para compartir los datos. Hay muchas maneras de hacer esto.

Una aplicación moderadamente compleja eventualmente se verá como una estructura de front-end back-end, con el manejo de datos realizado en servicios, exponiendo los datos a través de observables a los componentes.

En un momento, necesitará escribir algún tipo de api para sus servicios de datos, cómo ingresar y sacar datos, consultas, etc. Muchas reglas como la inmutabilidad de los datos y rutas únicas bien definidas para modificar los datos. No muy diferente al backend del servidor, pero mucho más rápido y receptivo que las llamadas a la API.

Su api terminará pareciendo una de las muchas bibliotecas de administración estatal que ya existen. Existen para resolver problemas difíciles. Es posible que no los necesite si su aplicación es simple.