shareReplay and take operators - some question

Viewed 31

I have 2 issues with rxjs and angular:

  1. I used shareReplay with refCount = true and bufferSize = 1 as for caching things which is great, but then I saw following thing: Consider you have this:

    const sourceObs: Observable<...> = ...
     const sharedObs1 = sourceObs.pipe(
     shareReplay({ bufferSize: 1,refCount: true }),
     take(1)
     )
    
     const sharedObs2 = sourceObs.pipe(
     take(1),
     shareReplay({ bufferSize: 1,refCount: true }),
    
     )
    

When we do following:

  sharedObs1 .subscribe(() => {
    setTimoue(() => sharedObs1.subscribe())
    })

Then, sourceObs would be subscribed again, in the timeout callback handler, using a new ReplaySubject for multicasting... is it ok? or a bug?

When we do following:

   sharedObs2 .subscribe(() => {
    setTimoue(() => sharedObs2.subscribe())
    })

Then, sourceObs is not subscribed again, in the timeout callback 2) I would like to say about angular guards: In a canActivate function, if you define a single var like this:

`enter code here`const source$:Observable<...> = ...
`enter code here`const usedObservable$ = source$.pipe(shareReplay({ bufferSize: 1,refCount: true }))

Let's imagin now, usedObservable$ is saved once somewhere... Then, let's say we define some route with a guard which as a canActivate, let's say you do this:

canActivate() {
return usedObservable$;
} 

Then everytime we hit the route, the guard runs, thus, canActivate, but I saw that the source$ is subscribed again and again even if it is attached by shareReplay... Now, I saw, in angular that they wrapped the result of canActivate with first:

... canActivateReturnedOBservable.pipe(**first**())...

Which is the reason for source$ to run every time, we hit the route.

I also opened a git discussion here, related only to rxjs, https://github.com/ReactiveX/rxjs/discussions/7067

What Do you think?

0 Answers
Related