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

84

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!

KevDing
fuente
7
El año pasado comencé un nuevo trabajo en una empresa. Estaban usando Angular con Redux. No he tocado Redux, pero he estado desarrollando en Angular desde su lanzamiento beta. Mi primera impresión fue ¿qué diablos es esto? Tanta complicación solo para comunicarse con API y suscribirse a esos datos. ¡Literalmente usaron Redux para todo! Era un desastre tal que era imposible trabajar. Realmente no es necesario integrar Redux / Ngrx a una aplicación Angular. Puedes hacer todo de la 'manera angular'
Dino
3
NgRx aumenta exponencialmente la complejidad del código con una gran cantidad de código repetitivo innecesario. Por otro lado, apenas ofrece nada más allá de lo que Angular, como marco completo, ya ha ofrecido fuera de la caja. Esta publicación de blog cubre toda la información que necesita: Administración del estado de la aplicación angular: usted (no) necesita almacenes de datos externos
seidme

Respuestas:

35

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

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
Jean-baptiste Courvoisier
fuente
9

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.

Aleksa
fuente
4
No funciona en AOT si el servicio se inyecta como privado. La mejor práctica es no exponer un servicio a la plantilla de un componente. Más bien, mantenga una variable en el componente y consígala / configúrela en función de la variable del servicio.
Srichandradeep C
2

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.

Derek Kite
fuente