Using rxjs, I have an expensive computation that maps the result coming out of a BehaviorSubject:
const obs$ = sameBehaviorSubject.pipe(map(expensiveComputation));
Then in multiple other parts of my code I subscribe to that observable. Each time I subscribe, it re-runs expensiveComputation. How can I prevent that?
You can use shareReplay:
const obs$ = sameBehaviorSubject.pipe(map(expensiveComputation), shareReplay(1));
Now you can subscribe to obs$ multiple times without doing expensiveComputation multiple times.
Update: I've included this in a (very) small library of rxjs utils I've wanted in the past. It is the cache function available in s-rxjs-utils.
#siva636 gave this great answer: add shareReplay(1). It does exactly what I asked.
I add this answer to show another alternative, with one small difference that turned out to be very important for me: add publishReplay(1), refCount(). So the solution is:
const obs$ = someBehaviorSubject.pipe(
map(expensiveComputation),
publishReplay(1),
refCount(),
);
The difference occurs when the last subscriber unsubscribes from obs$: shareReplay(1) will keep its subscription open to someBehaviorSubject, whereas this solution will unsubscribe. I am creating these observables in Angular components that come and go over time, so it's important to me that when they are destroyed they completely clean up after themselves. shareReplay(1) leaked subscriptions that continued to build up over time, this solution does not.
Related
I have a NestJS application, and need to send an HTTP request to another server, so I am using the HttpModule (#nestjs/axios).
I need the data from that request, but the returned type is <Observable<AxiosResponse<any,any>>, where I need just the AxiosResponse.
Reading over the RxJS documentation, it looks like the prescribed way to handle this situation is to make use of RxJS lastValueFrom() or firstValueFrom(), after the deprecation of toPromise().
However, there is a warning attached:
Only use lastValueFrom function if you know an Observable will eventually complete. The firstValueFrom function should be used if you know an Observable will emit at least one value or will eventually complete. If the source Observable does not complete or emit, you will end up with a Promise that is hung up, and potentially all of the state of an async function hanging out in memory. To avoid this situation, look into adding something like timeout, take, takeWhile, or takeUntil amongst others.
The solution that I came up with was:
const response = this.httpService.post('the-url').pipe(take(1))
const axiosResponse: AxiosResponse = await lastValueFrom(response)
TypeScript at least is not complaining. Is this a suitable way to get at the underlying Axios response?
A promise once triggered will only get resolved or rejected once. Once it's resolved the observable is completed. It is one of the major differences between promise and observable which has capability to emit multiple times like callback.
Therefore there is no need to add pipe(take(1)), just use lastValueFrom is sufficient
If you construct an observable from a promise you don't need lastValueFrom nor take. Once subscribed to, it emits once then completes immediately:
const {from} = rxjs;
const answer$ = from(Promise.resolve(42));
answer$.subscribe({
next(x) {
console.log(`answer=${x}`);
},
complete() {
console.log('done');
}
});
<script src="https://unpkg.com/rxjs#%5E7/dist/bundles/rxjs.umd.min.js"></script>
I want to make sure that all events, which were submitted before complete was invoked on the observable, are logged.
I'm aware that operators exist that stop emission of events (takeUntil, etc.) completely.
The question that I have is whether other operators exist which would lead to emissions not being sent if the complete on the subject is sent too 'early'. Are there cases where it would be beneficial to wait with the completion of the observable until the event was handled by the observer?
For example, are there situations (imagine any other RxJS operator instead of the delay) where the following code ...
const subj = new Subject<string>();
subj.pipe(delay(500))
.subscribe((val) => {
console.log(val);
subj.complete();
});
subj.next('1');
... makes more sense than that ...
const subj = new Subject<string>();
subj.pipe(delay(500))
.subscribe((val) => {
console.log(val);
});
subj.next('1');
subj.complete();
... when the subject should only emit one value?
Or is completing the subject immediately after next always safe in such situations?
If there are other factors I'm not aware of (e.g. synchronous vs. asynchronous execution of code) please mention them as well.
In general,
subj.next('1');
subj.complete();
is safe. As far as I know, none of the existing RxJS operators use a completion to cancel/unsubscribe observables early.
That being said, I can easily create such an operator myself. switchMap will cancel currently running inner observables when it receives it's next emission. You could, for example, create a custom operator that unsubscribes and exists early when it receives a complete event.
If your worried about that, however, you're out of luck. No matter what workaround you imagine, I can probably write an operator that will ruin your code. For example filter(_ => false) will stop the 1 from being emitted before the complete in either of the two cases you've described.
In the end, you and your coworkers must write good code (and test!) and RxJS doesn't change that.
I need to lazy load some infinite streams because they are expensive to start. And I also don't ever want to stop them once they are started for the same reason.
I'm thinking it would be neat if there was a share operator that didn't unsubscribe from the underlying stream ever once it is subscribed for the first time, even when all downstream subscribers unsubscribe.
Right now I'm doing it with a publish and a connect on two different lines, which works alright but just seems clunky and not very rxjs like:
public data$(): Observable<any> {
if (this.lazyData$) {
return this.lazyData$;
}
this.lazyData$ = this.someDataProvider.data$()
.publishReplay(1);
this.lazyData$.connect();
return this.lazyData$;
}
Also I want it to replay the last message to new subscribers as you see :)
The shareReplay operator was added in RxJS version 5.4.0. And, in version 5.5.0 a bug was fixed so that it maintains its history when its subscriber count drops to zero.
With the fix, shareReplay will effect the behaviour you are looking for, as it will now unsubscribe from the source only when the source completes or errors. When the number of subscribers to the shared observable drops to zero, the shared observable will remain subscribed to the source.
The behaviour of shareReplay has changed several times and a summary of the changes - and the reasons for them - can be found in this blog post.
As of RxJS 6.4.0, you can specify shareReplay refCount behavior.
source.pipe(
shareReplay({ bufferSize: 1, refCount: true })
)
shareReplay will unsubscribe from source after all subscribers have unsubscribed.
I am just getting into RxJs and Observables in general. I grasped the idea that often you can create "self-contained" Observable by utilizing "takeUntil()".
In one online-course I am watching the teacher says "I did not unsubscribe from anything in 10 years because I always use takeUntil() to create ending streams of events". This is his example:
var getElementDrags = elmt => elmt
.mouseDowns.map(() => document.mouseMoves.takeUntil(document.mouseUps))
.concatAll();
That is very nice for the "inner" Observables. But the one outer Observable on "mousedown" never really gets unsubscribed from...
Do we still need to unsubscribe from those?
Is it still good practice to unsubscribe/dispose when the user leaves the page?
In example you have - you are not subscribing to anything... RxJS is lazy, and it will subscribe to mouseDowns only when you will subscribe to resulting observable, and of course - it will unsubscribe from underlining observables when you will unsubscribe from resulting observable.
But, generally - yes, it is a good practice to unsubscribe when you are subscribing to something… But - while using RxJS, typically you will not need to subscribe manually, and when you need - chances are that you need subscription while app is running(so no need to unsubscribe).
The only exceptions are - when you are developing own operators, or connecting to something outside…
For example if you have react component and use life-cycle hocks for subscription to updates on mount, and unsubscribe when un-mounting.
Here is my library for that purpose https://github.com/zxbodya/rx-react-container - it combines observables, subjects and react component into new observable with renderable items...
const app$ = createContainer(
App, // react component
{totalCount$}, // observables with data
{plusOne$, minusOne$} // observers for user actions
);
const appElement = document.getElementById('app');
const appSubscription = app$.forEach(renderApp=>render(renderApp(), appElement));
In result you have only one subscription to manage for a whole application(appSubscription), and no need to unsubscribe - since it is used while app is running.
The same thing, about routing and unsubscribe when navigating away - in simplified case you will have just flatMapLatest over observable with current location, that will return observable(like app$ above) for each location… And again you do not need to subscribe/unsubscribe manually - flatMapLatest will do it internally.
This is what I have:
CitiesObservable = Observable
.FromAsync(apiClient.GetCitiesTask)
.Retry();
apiClient.GetCitiesTask returns a task of type: Task<List<City>>
The problem is that every time I add a subscriber to the observable, apiClient.GetCitiesTask gets called again. How can I cache the result once it has completed successfully?
Thanks
Question reworded
I want apiClient.GetCitiesTask to be called as many times as needed (until it doesn't fail), but once it success, all late subscribers should use a cached result.
Conclusion
2 solutions arose, one I found and the other (the selected answer).
Solution A: (actually is almost a solution)
CitiesObservable = Observable.FromAsync(apiClient.GetCitiesTask).Publish();
CitiesObservable.Connect();
// Then you can subscribe as you want. But! you won't receive the cached value on late subscribers, only the onCompleted signal.
Solution B: (by #Bluesman)
CitiesObservable = Observable.StartAsync(
() => Observable.FromAsync(apiClient.GetPlacesTask<City>).Retry().ToTask()
);
// Then you can subscribe as you want.
What about....
Observable
.StartAsync(() => Observable
.FromAsync(reserbusAPI.GetPlacesTask<City>)
.Retry()
.ToTask());
The outer StartAsync makes sure the eventual result from the created task is buffered while the inner FromAsync with Retry makes sure that GetPlacesTask is called as many times as needed. However, the whole retrying-thing still starts even before the first subscription.