tap() vs subscribe() para establecer una propiedad de clase

Te recomendamos que pruebes esta solución en un ambiente controlado antes de pasarlo a producción, saludos.

Solución:

Buena pregunta. En el código fuente de la tap operador, este comentario lo resume bastante bien:

Este operador es útil para depurar sus Observables para obtener los valores correctos o realizar otros efectos secundarios.
Nota: esto es diferente a un subscribe en el Observable. Si el Observable regresa por do no está suscrito, los efectos secundarios especificados por el Observador nunca ocurrirán. do por lo tanto, simplemente espía la ejecución existente, no desencadena una ejecución como subscribe lo hace.

Cualquier efecto secundario que pueda ejecutar en un tap probablemente también se puede poner en el subscribe cuadra. El subscribe indica su intención de usar activamente el valor fuente ya que dice “cuando este observable emite, quiero guardar su valor en el applicants variable”. La tap operador está allí principalmente para la depuración, pero poder utilizarse para ejecutar efectos secundarios.

En general, favorezca la subscribe bloque para ejecutar efectos secundarios, use tap para la depuración, pero tenga en cuenta que tap puede hacer más si lo necesita.

tap es útil cuando tiene el observable separado de su suscriptor. Si tiene una clase que expone un observable, puede usar tap para implementar los efectos secundarios que esta clase necesita ejecutar cuando alguien está escuchando a lo observable. Por otro lado, cuando te suscribes desde otra clase, puedes implementar efectos secundarios desde el punto de vista del suscriptor, usando subscribe.

Clase con el observable:

public dummyObservable: Observable = from([1, 2, 3, 4, 5]).pipe(
  // Side effects, executed every time I emit a value
  // I don't know which side effects implements who subscribes to me
  tap( n => console.log("I'm emitting this value:", n) )
);

Clase con la suscripción:

ngOnInit(): void 
  this.dummyService.dummyObservable.subscribe(
    // Side effects, executed every time I receive a value
    // I don't know which side effects implements the observable
    data => console.log("I'm receiving this value: ", data)
  );

Michael Hladky sugiere que ponga todos los efectos secundarios en el operador del grifo y explica por qué aquí.

Creo que, en general, es una buena idea hacerlo porque, como dice Michael, puede combinar muchos observables y crear una sola suscripción para todos ellos.

No sé si esto mejora el rendimiento o no, pero definitivamente lo hace más fácil cuando desea darse de baja para tener solo una suscripción. Darte de baja es algo que siempre debes hacer para evitar posibles pérdidas de memoria u otros comportamientos extraños.

Otra ventaja de este enfoque es que puede pausar, reanudar o completar fácilmente un grupo de observables al canalizarlo a través de operadores como filter o takeWhile, o cambiarlo a través de otro observable como este:

const allMergedObservables$ = merge(obs1, obs2, obs3);
const play$ = new Subject();

play$.asObservable().pipe(
    switchMap(bool => bool ? allMergedObservables$ : EMPTY)
).subscribe();

// Putting 'true' into the play stream activates allMergedObservables$. 
play$.next(true);

// Something happens that makes you want to pause the application,
// for instance the user opens the print dialog box,
// so you issue 'false' in the play stream which in turn stops the
// inner subscription of allMergedObservables$:
play$.next(false);

Sin embargo, depende de usted y del estilo de programación que prefiera.

Te mostramos las comentarios y valoraciones de los usuarios

Tienes la opción de corroborar nuestra publicación escribiendo un comentario y puntuándolo te estamos eternamente agradecidos.

---

---

Utiliza Nuestro Buscador