angular - forkjoin - Rendimiento del uso del mismo observable en múltiples lugares en la plantilla con una tubería asíncrona

return observable angular 4

Question

En mi plantilla de componentes, estoy llamando a una tubería async para el mismo observable en 2 lugares.

¿Debo suscribirme a él y usar la matriz devuelta en mi plantilla o usar una tubería async para el mismo Observable en varios lugares de la plantilla no tiene ningún efecto negativo en el rendimiento?

Answer 1

Cada uso de observable$ | async observable$ | async creará una nueva suscripción (y, por lo tanto, un flujo individual) para el observable$ dado - si este observable contiene partes con cálculos pesados ​​o llamadas de descanso, esos cálculos y llamadas de descanso se ejecutan individualmente para cada async - entonces sí, esto puede tienen implicaciones de rendimiento.

Sin embargo, esto se arregla fácilmente extendiendo su observable$ con .share() , para tener un flujo compartido entre todos los suscriptores y ejecutar todas esas cosas solo una vez para todos los suscriptores. No olvide agregar el operador share con la import "rxjs/add/operator/share";

La razón por la que async-pipe no comparte las suscripciones de forma predeterminada es simplemente la flexibilidad y la facilidad de uso: un simple .share() es mucho más rápido de escribir que de crear un flujo completamente nuevo, que sería necesario si fueran compartidos por defecto.

Aquí hay un ejemplo rápido

@Component({
selector: "some-comp",
template: `
Sub1: {{squareData$ | async}}<br>
Sub2: {{squareData$ | async}}<br>
Sub3: {{squareData$ | async}}
`
})
export class SomeComponent {
squareData$: Observable<string> = Observable.range(0, 10)
.map(x => x * x)
.do(x => console.log(`CalculationResult: ${x}`)
.toArray()
.map(squares => squares.join(", "))
.share(); // remove this line and the console will log every result 3 times instead of 1
}

Answer 2

Otra forma de evitar las suscripciones múltiples es usar un *ngIf="obs$ | async as someName" . Usando el ejemplo de olsn.

 @Component({
selector: "some-comp",
template: `
<ng-container *ngIf="squareData$ | async as squareData">
Sub1: {{squareData}}<br>
Sub2: {{squareData}}<br>
Sub3: {{squareData}}
</ng-container>`
})
export class SomeComponent {
squareData$: Observable<string> = Observable.range(0, 10)
.map(x => x * x)
.do(x => console.log(`CalculationResult: ${x}`)
.toArray()
.map(squares => squares.join(", "));
}

También es genial porque limpia la plantilla un poco también.

Answer 3

Tuve mejor suerte con .shareReplay de ''rxjs / add / operator / shareReplay'' que es muy nuevo ( https://github.com/ReactiveX/rxjs/pull/2443 )

También tuve suerte con .publishReplay.refCount (1) ( Angular 2 + rxjs: tubo asíncrono con el operador .share () )

Sinceramente, no estoy seguro de la diferencia entre las dos estrategias. Los comentarios en el PR para shareReplay sugieren que podría haber más riesgo de fugas de memoria de las suscripciones si no se implementan correctamente, por lo que podría ir con .publishReplay.refCount (1) por ahora.