page - change title angular 4

¿Por qué utilizarías un resolutor con Angular?

Question

Me gusta la idea de resolver s.

Puedes decir eso:
- para una ruta determinada esperas que algunos datos se carguen primero
- simplemente puede tener un componente realmente simple sin observable (como recuperar datos de this.route.snapshot.data )

Así que los resolutores tienen mucho sentido.

PERO:
- No está cambiando la URL y mostrando el componente solicitado hasta que reciba la respuesta real. Por lo tanto, no puede (simplemente) mostrar al usuario que algo está sucediendo al representar su componente y mostrar todo lo que puede (como se recomienda, para la aplicación de shell con PWA). Lo que significa que al tener una mala conexión, su usuario puede tener que esperar sin una indicación visual de lo que está sucediendo durante mucho tiempo.
- Si está utilizando un resolutor en una ruta con param, tomemos como ejemplo users/1 , funcionará bien la primera vez. Pero si va a los users/2 , nada ocurrirá a menos que comience a usar otro observable: this.route.data.subscribe()

Así que parece que los resolutores pueden ser útiles para recuperar algunos datos, PERO en la práctica no los usaría en caso de que haya una red lenta y especialmente para rutas con parámetros.

¿Me estoy perdiendo de algo? ¿Hay alguna manera de usarlos con esas restricciones reales?

Answer 1

El resolutor le da un gancho cerca del inicio de la navegación del enrutador y le permite controlar el intento de navegación. Esto te da mucha libertad, pero no muchas reglas duras y rápidas.

No tiene que usar el resultado de la resolución en su componente. Puedes usar la resolución como un gancho. Esta es mi forma preferida de usarla por las razones que ha citado. Usar el resultado en su componente es mucho más simple, pero tiene esas compensaciones sincrónicas.

Por ejemplo, si está usando algo como Material o Cdk, podría enviar un cuadro de diálogo de "carga" para mostrar un indicador de progreso al inicio de la resolución, luego cerrar el cuadro de diálogo cuando la resolución concluya. Al igual que:

constructor(route: ActivatedRouteSnapshot, myService: MyService, dialog: MatDialog) {}

resolve() {
    const dialogRef = this.dialog.open(ProgressComponent);
    return this.myService.getMyImportantData().pipe(
        tap(data => this.myService.storeData(data)),
        tap(() => dialogRef.close()),
        map(() => true),
        catchError(err => of(false))
    );
}

Si está utilizando ngrx , podría hacer algo similar mediante el envío de acciones mientras la resolución está en curso.

Cuando está utilizando el protector de resolución de esta manera, no hay una razón particularmente fuerte para usar el protector de resolución en lugar del protector de activación de CanA. Esa elección se reduce a la semántica. Me parece más obvio que la autenticación de puerta en CanActivate e inicie la recuperación de datos desde Resolver. Cuando se permite que esos temas se mezclen, se convierte en una opción fundamental.

Answer 2

Es por esto que usaría un resolutor:

• Responsabilidad individual, mi componente necesita algunos datos, en algunos casos, estos datos son proporcionados por un caché o estado, cuando faltan, primero necesito recuperarlos y pasarlos directamente, sin cambiar mi componente. Ejemplo : Una página de resultados de búsqueda con una lista myapp.com/lists , navegue a un elemento de la lista myapp.com/lists/1 , mostrando los detalles de ese elemento, sin necesidad de obtener los datos, ya realizados por la búsqueda. Luego supongamos que navega directamente a myapp.com/lists/1 que necesita buscar y luego navegar al componente
• Aísla tu componente de la lógica del enrutador
• Mi componente no debe administrar el estado de carga de una solicitud de recuperación, solo la responsabilidad es mostrar los datos

Piense en el resolvedor como un middleware entre su aplicación y su componente, puede administrar la vista de carga en el componente principal, donde se incluye <router-outlet> .

Answer 3

Resolución: se ejecuta incluso antes de que el usuario se dirija a una nueva página.

Siempre que necesite obtener los datos antes de la inicialización del componente, la forma correcta de hacerlo es usar el sistema de resolución. La resolución actúa de forma sincrónica, es decir, la resolución esperará a que se complete la llamada asíncrona y, solo después de procesar la llamada asíncrona, se enrutará a la URL correspondiente. Por lo tanto, la inicialización del componente esperará hasta que se complete la devolución de llamada. Por lo tanto, si desea hacer algo (llamada de servicio), incluso antes de que se inicialice el componente, ha llegado al lugar correcto.

Escenario de ejemplo: estaba trabajando en el proyecto donde el usuario pasaría el nombre del archivo que se cargaría en la URL. Basándonos en el nombre pasado, haríamos la llamada asíncrona en ngOnInit y obtendríamos el archivo. Pero el problema con esto es que, si el usuario pasa el nombre incorrecto en la URL, nuestro servicio intentará recuperar el archivo que no existe en el servidor. Tenemos 2 opciones en tal escenario:

Opción 1: para obtener la lista de nombres de archivo válidos en ngOnInit, y luego llamar al servicio real para obtener el archivo (si el nombre del archivo es válido). Ambas de estas llamadas deben ser sincrónicas .

Opción 2: Obtenga la lista de nombres de archivo válidos en el resolutor, verifique si el nombre de archivo en la URL es válido o no, y luego busque los datos del archivo.

La opción 2 es una mejor opción, ya que el resolvedor maneja la sincronicidad de las llamadas.

Importante: use la resolución cuando desee recuperar los datos incluso antes de que el usuario se dirija a la URL. Resolver podría incluir llamadas de servicio que nos traerían los datos necesarios para cargar la página siguiente.