I have mousemove event:
fromEvent(document, 'mousemove').pipe(
filter(e => e.target !== this.formElement.nativeElement),
filter(_ => this.form.valid),
take(1),
mergeMap((): any => this.confirm()),
).subscribe();
confirm() {
this.snack.open('sure', 'yes').onAction()
.subscribe(_ => {
this.createNoteService.create();
})
}
After confirming the snack button I want the mouse event to start working again.
Is it possible? Thanks!
The reason this only works for you the first time, is because you have take(1) which ends the observable after one value is received.
Also, your confirm() method should return observable; don't subscribe inside the function; mergeMap will automatically subscribe / unsubscribe for you.
However, instead of mergeMap, you can use exhaustMap. This will only allow a single inner subscription at a time. It will ignore any incoming emissions until its current source completes:
fromEvent(document, 'mousemove').pipe(
filter(e => e.target !== formElement.nativeElement),
filter(_ => form.valid),
exhaustMap(() => confirm()),
).subscribe();
function confirm() {
return snack.open('sure', 'yes').onAction().pipe(
tap(() => this.createNoteService.create())
);
}
Related
I have some javascript:
this.mySubscription = someObservable.subscribe((obs: any) => {
this.mySubscription.unsubscribe();
this.mySubscription = undefined;
}
on execution, the console logs the error ERROR TypeError: Cannot read property 'unsubscribe' of undefined.
I wonder why I can not unsubscribe inside the subscribe lambda function. Is there a correct way to do so? I have read a bit about using dummy-subjects and completing them or using takeUntil/takeWhile and other pipe operators workArounds.
What is a correct way/workaround to unsubscribe a subscription inside the subscription's subscribe-function?
I am currently using a dummy subscription like so:
mySubscription: BehaviorSubject<any> = new BehaviorSubject<any>(undefined);
// when I do the subscription:
dummySubscription: BehaviorSubject<any> = new BehaviourSubject<any>(this.mySubscription.getValue());
this.mySubscription = someObservable.subscribe((obs: any) => {
// any work...
dummySubscription.next(obs);
dummySubscription.complete();
dummySubscription = undefined;
}, error => {
dummySubscription.error(error);
});
dummySubscription.subscribe((obs: any) => {
// here the actual work to do when mySubscription emits a value, before it should have been unsubscribed upon
}, err => {
// if errors need be
});
You shouldn't try to unsubscribe in the subscribe function.
You can unsubscribe with operators like take, takeWhile or takeUntil.
take
Use take(n) to unsubscribe after someObservable emits n times.
someObservable.pipe(
take(1)
).subscribe(value => console.log(value));
takeWhile
Use takeWhile to unsubscribe when an emitted value fails a condition.
someObservable.pipe(
takeWhile(value => valueIsSave(value))
).subscribe(value => console.log(value));
valueIsSave(value): boolean {
// return true if the subscription should continue
// return false if you want to unsubscribe on that value
}
takeUntil
Use takeUntil(obs$) to unsubscribe when the observable obs$ emits.
const terminate = new Subject();
someObservable.pipe(
takeUntil(terminate)
).subscribe(value => console.log(value));
unsub() {
terminate.next() // trigger unsubscribe
}
If you make your stream asynchronous, what you're doing should work. For example, this will not work:
const sub = from([1,2,3,4,5,6,7,8,9,10]).subscribe(val => {
console.log(val);
if(val > 5) sub.unsubscribe();
});
but this will work:
const sub2 = from([1,2,3,4,5,6,7,8,9,10]).pipe(
delay(0)
).subscribe(val => {
console.log(val);
if(val > 5) sub2.unsubscribe();
});
Because the JS event loop is fairly predictable (blocks of code are always run to completion), If any part of your stream is asynchronous, then you can be sure that your subscription will be defined before your lambda callback is invoked.
Should you do this?
Probably not. If your code relies on the internal (otherwise hidden) machinations of your language/compiler/interpreter/etc, you've created brittle code and/or code that is hard to maintain. The next developer looking at my code is going to be confused as to why there's a delay(0) - that looks like it shouldn't do anything.
Notice that in subscribe(), your lambda has access to its closure as well as the current stream variable. The takeWhile() operator has access to the same closure and the same stream variables.
from([1,2,3,4,5,6,7,8,9,10]).pipe(
takeWhile(val => {
// add custom logic
return val <= 5;
})
).subscribe(val => {
console.log(val);
});
takeWhile() can to anything that sub = subscribe(... sub.unsubscibe() ... ), and has the added benefit of not requiring you to manage a subscription object and being easier to read/maintain.
Inspired by another answer here and especially this article, https://medium.com/#benlesh/rxjs-dont-unsubscribe-6753ed4fda87, I'd like to suggest takeUntil() with following example:
...
let stop$: Subject<any> = new Subject<any>(); // This is the one which will stop the observable ( unsubscribe a like mechanism )
obs$
.pipe(
takeUntil(stop$)
)
.subscribe(res => {
if ( res.something === true ) {
// This next to lines will cause the subscribe to stop
stop$.next();
stop$.complete();
}
});
...
And I'd like to quote sentence RxJS: Don’t Unsubscribe from those article title mentioned above :).
Consider the following:
a$ = someObservable$.pipe(
switchMap(data => liveForEver$)
);
a$.subscribe();
a$.unsubscribe();
Now, liveForEver$ as the name suggests is subscribed to by other parts of the code. Could it be that a$ will stay subscribed after a$ is unsubscribed because switchMap returns a 'living' observable?
When an operator is defined, it usually has behavior to unsubscribe to child subscriptions when it is unsubscribed to. If you make a custom operator and fail to do this, then you'll likely create memory leaks. Consider the following custom operator:
function timesTwo(input$: Observable<number>): Observable<number> {
return new Observable<number>(observer => {
input$.subscribe({
next: val => observer.next(val * 2),
complete: () => observer.complete(),
error: err => observer.error()
});
return {
// I should $input.unsubscribe()
unsubscribe: () => {/*Do Nothing*/}
}
});
}
function timesTwoPipeable<T>(): MonoTypeOperatorFunction<T> {
return input$ => timesTwo(input$);
}
Here I've created my own custom rxjs operator that multiplies a stream of inputs by two. So 1:
const subscription = interval(1000).pipe(map(x => x * 2))
.subscribe(console.log);
setTimeout(() => subscription.unsubscribe(), 5000);
and 2:
const subscription = timesTwo(interval(1000))
.subscribe(console.log);
setTimeout(() => subscription.unsubscribe(), 5000);
and 3:
const subscription = interval(1000).pipe(timesTwoPipeable())
.subscribe(console.log);
setTimeout(() => subscription.unsubscribe(), 5000);
All have identical outputs to the console, but 2 and 3 both subscribe to the interval stream and then do not unsubscribe to it. So the second two quietly create a memory leak. You could test this yourself by changing interval(1000) to interval(1000).pipe(tap(_ => console.log("Still Alive"))) in all three examples.
All the built-in RxJS operators clean up after themselves. If you build your own, be sure to do the same!
Something I noticed in your question is that you tried to unsubscribe to an observable. I'm surprised that didn't create an error.
My inderstanding is that:
a$.subscribe();
a$.unsubscribe();
should be:
const sub = a$.subscribe();
sub.unsubscribe();
I try to use rxjs rety operator, its work fine with observable:
const obs$: Observable<number> = new Observable((observer) => {
observer.next(1);
observer.complete();
});
obs$
.pipe(
mergeMap(async () => [
await dataService.getAllSomthing(),
await dataService.getAllomthingElse(),
await dataService.getAllSomthingElseElse(),
]),
map(([somthing, somthingElse, somthingElseElse]) => {
dispatch(
enableToasterAction({
text: "good",
type: ToasterType.Success,
})
);
}),
retry(2),
catchError((err) => {
return of(null);
})
)
.subscribe((val: any) => {});
But its not work when I using Subject:
const sub=new Subject();
sub
.pipe(
switchMap(async ({ somthinng}: any) => {
return [await dataService.getSomthing(somthinng)];
}),
map(([somthinngRes]) => {
dispatch(
enableToasterAction({
text: "good",
type: ToasterType.Success,
})
);
}),
retry(2),
catchError((err) => {
return of(null);
})
)
.subscribe((val: any) => {});
sub.next({});
Someone can help me to understand what the difference between them, why its work with observable, but not with subject ?
You can retry an cold observable but not hot observable (subject)
if you want to retry a action trigger by hot observable, you can however move the retry() operator to inner observable. For example
fromEvent(document,'click').pipe(
switchMap(evt=>from(fetch('someurl')).pipe(retry(2))
)
That way the http call triggered by click will retry 2 times when it fails
Subject has an internal state and once it receives complete or error notification it marks itself as isStopped and will never ever emit anything.
So retry() tries to resubscribe but the source Subject will just return Subscription.EMPTY and won't make a real subscribtion.
I have the following code:
this.userService.get().pipe(
catchError(() => EMPTY) // Do something here
).subscribe(() => {}) // And here
I want to do some stuff no matter there was an error or not. Just like finalize but for not completed observable. I tried to use tap, but it works only if there's no error. I don't want to duplicate my code and add it to the catchError. What should I do?
there's no other way to do it with catchError without touching it in the current example . Because everything after catchError won't get any notification, it's like an observable that never emits.
you can use 2nd argument of tap, it is triggered on error, the same as in subscribe.
this.userService.get().pipe(
tap(
() => console.log('emit'),
() => console.log('error'),
() => console.log('complete'),
),
// catchError(() => EMPTY), // closing the stream and hiding the error.
// repeat(), // in case if you want to resubscribe once the stream has been closed.
).subscribe(
() => console.log('emit'),
() => console.log('error'),
() => console.log('complete'),
);
Emit a default value in catchError.
this.userService.get().pipe(
catchError(() => of(null)) // catch error and emit null instead (or some other value)
).subscribe(value => {
// do something here,
// value will be null when this.userService.get() errors */
})
You should consider moving your error handling with catchError into the Service.
I have a pipeline that ends with takeUntil, the problem is switchMap is getting triggered because the combineLatest is not canceled till the taps inside takeUntil end.
My pseudocode:
combineLatest(
fromEventPattern(handler => {
document.addEventListener('disconnect', handler, false);
console.log('added');
},
handler => {
document.removeEventListener('disconnect', handler, false);
console.log('removed');
}
).pipe(
switchMap(() => {
console.log('SWITCH MAP TRIGGERED!');
return EMPTY;
]),
takeUntil(
mySubject.pipe(
filter(type => type === 'LOGOUT'),
tap(() => console.log('got logout, so do logout calls'),
tap(() => document.dispatchEvent(new CustomEvent('disconnect')))
)
)
)
Trigger the cancelation with:
mySubject.next({ type: 'LOGOUT' });
The problem I'm having is that it's not removing the event listenrs until after the taps in takeUntil finish. Due to this, the dispatch of the "disconnect" event is triggering the switchMap to trigger again. I want things to cancel immediately as the filter in takeUntil is met, and then it should do that final action of dispatchEvent('disconnect').