page navigationend example change javascript angular angular-services

javascript - navigationend - Angular v4: ¿Almacenamos datos en un Servicio o en el Componente o ambos?



change title angular 4 (4)

En términos generales, desea almacenar datos en un servicio si muchos componentes utilizan los mismos datos. De esa manera, hace que sea extremadamente fácil acceder a los mismos datos desde todas las diferentes partes de su aplicación. Si un componente modifica los datos en el servicio, se modificará para todos los componentes que usan los datos, lo que generalmente es muy útil. Sin embargo, a veces es innecesario si solo necesita enviar datos de un componente a otro, donde uno es el padre del otro. En este escenario, se recomienda el uso de entrada / salida.

Si no necesita enviar los datos específicos entre varios componentes, entonces el almacenamiento de los datos en un componente es perfectamente aceptable. Tenga en cuenta que no será accesible desde otros componentes a menos que use entrada / salida.

Angular v4: ¿Almacenamos datos en un Servicio o en el Componente o ambos?

Después de revisar bastantes tutoriales y leer la documentación de Angular, todavía no tengo claro este tema.

https://angular.io/tutorial/toh-pt2 El tutorial de Angular muestra claramente los datos almacenados en el Componente.

https://angular.io/guide/architecture#services La sección Arquitectura> Servicios de Angular muestra código con el servicio que tiene una matriz de datos (¿es esto correcto?).

Si almacenamos datos en Componentes , utilizaríamos mucho @Input y @Output para mover datos entre componentes secundarios (suponiendo que deseamos estos datos en el extremo delantero), sin embargo esto plantea un problema cuando usamos enrutamiento, necesitaríamos nuestro nuevo Componente que se cargó desde la salida del enrutador para realizar una nueva llamada a nuestro servicio con la promesa de realizar la llamada a la API a nuestro servidor para almacenar datos. Posiblemente en este caso tendríamos 2 componentes con los mismos datos, sin embargo, pueden no coincidir.

Si almacenamos datos en un Servicio , usaríamos nuestros Servicios para recuperarlos y manipularlos (suponiendo que deseamos estos datos en el extremo delantero), de esta manera nuestro servicio contiene 1 conjunto de datos, y cada componente puede llamar al servicio. Datos en cualquier momento para obtener datos consistentes.

-

¿Cuál es la forma correcta de almacenar datos? ¿Es uno de los otros no aconsejado?


Los controladores de componentes solo deben administrar las interacciones de UI para ese componente específico.

Los servicios, por otro lado, gestionan las interacciones entre componentes, mapeo de datos, manejo de eventos entre componentes que no tienen una relación directa (padre> hijo, hermanos, etc.).

La idea detrás de esto es que una vez que se crea un servicio, permanece en el alcance y no se destruye. Los componentes en la otra mano se eliminan del DOM después de que se destruyen. Dicho esto, si usa su componente para hacer, por ejemplo, llamadas a la API para recopilar datos, esta llamada a la API se realizará cada vez que el componente se inicialice en el ciclo de vida del marco, mientras que los servicios, como ya se mencionó, persistirán.

La persistencia de los servicios también nos permite usar cosas como los observables, para mantener siempre esa línea directa entre el front-end y el back-end.

Esperemos que esto ayude.

EDITAR

Tenga en cuenta que el tutorial de Angular.io está separado en varias secciones para ayudar a proporcionar una introducción completa al marco a medida que el usuario sigue el tutorial.


Si varios componentes comparten datos, póngalos en un servicio ... cuando sea posible. Digo cuando es posible, porque al hacer que el servicio administre los datos, ahora tiene que preocuparse por los datos obsoletos. Mi ubicación de almacenamiento de datos goto está en el Componente, pero debe tener cuidado al hacer esto, ya que no desea que el sitio tenga que recuperar datos todo el tiempo.

Personalmente, la mayoría de mis componentes gestionan sus propios datos para evitar problemas de datos obsoletos.

Si no está preocupado por esto, incluso podría usar un servicio de almacenamiento en caché, que, en lugar de almacenar los datos en el ram, los almacenará en el almacenamiento local o en el almacenamiento de la sesión, para asegurarse de que el sitio no se ralentice con un montón de Datos que se ponen en las computadoras RAM.

Sin embargo, no soy un experto en esto, solo es mi opinión.


Usted sabe que @Output está relacionado con un derecho EventEmitter, por lo que los datos se comparten entre componentes mediante el enlace a eventos. Los servicios son donde convencionalmente haces algo como una solicitud Http, algo como RESTFUL api. También podría ser almacenamiento local, conectividad de red o como un depósito para almacenar el estado mientras se ejecuta la aplicación. Los componentes están asociados en general a las vistas y utilizan el DOM de sombra