I have created this example to demonstrate the issue: https://stackblitz.com/edit/rxjs-vxvmq1?file=index.ts&devtoolsheight=100
Basically I want to call a function (e.g. cleanup as in the example) when a subject is completed. The function is called by others so not subscribing to the subject's changes, rather, a subscription is there to trigger the function for the completion of the subject. The function checks if it should do extra work when the subject is completed, so it checks if the subject has stopped or not. But it seems that once next() is called, the function is triggered before complete() is called, making the function thinks the subject has not been completed yet.
I wonder if there is any way to resolve this? Calling complete() first then next() didn't help as next() didn't notify the subscription after the subject has completed.
Long story short. It is all wrong.
Fix #1, not rxjs-idiomatic: you're subscribing wrongly: passing onNext callback, while you're interested in onComplete. There are three parameters taken by the subscribe: onNext, onError, onComplete and you are responsible for choosing the one you really need.
Fix #2, rxjs-idiomaric: you have to use pipe(...) along with operators defined in rxjs/operators (AFAIR). Note that it is easy to define your custom operator as well. So you either could use finalize(() => ...your cleanup logic goes here) or Observable.create returning finalizing logic as implementation of unsubscribe. Both nicely documented here or here.
In addition, seems that you're misunderstanding the semantics of rxjs. In terms of regex, it could be defined as next*(error|complete), which literally means: zero or infinitely many next's followed by either error or complete (exclusive or: never both simultaneously) exactly once. So don't expect next to do anything after complete (or equally error) fired.
Related
I have not been able to find any normative text to answer this question. I have been using this code pattern (this is in TypeScript in an Angular application):
observeSomethingFun$: Observable<Fun>;
...
async loadsOfFun() {
const fun = await this.observeSomethingFun$.toPromise();
// I now have fun
}
In general, Observables need to be unsubscribed from. This happens automatically when the Angular async pipe is used but what happens in this case? Does toPromise unsubscribe after emitting one value?
If not, how do I unsubscribe manually?
Update:
It turns out #Will Taylor's answer below is correct but my question needs some clarification.
In my case the Observable emits a never-ending stream, unlike for example Angular's HttpClient Observables that complete after emitting one value. So
in my case I would never get past the await statement according to Taylor's answer.
RxJS makes this easy to fix. The correct statement turns out to be:
const fun = await this.observeSomethingFun$.pipe(first()).toPromise();
The RxJS first operator will receive the first value and unsubscribe from the source Observable. it will then send out that value to the toPromise operator
and then complete.
No need to unsubscribe.
Which is convenient, as there is no way to unsubscribe from a promise.
If the Observable completes - the promise will resolve with the last value emitted and all subscribers will automatically be unsubscribed at this point.
If the Observable errors - the promise will reject and all subscribers will automatically be unsubscribed at this point.
However, there are a couple of edge cases with toPromise in which the behavior is not completely clear from the docs.
If the Observable emits one or more values but does not complete or error, the promise will neither resolve or reject. In this case, the promise would hang around in memory, which is worth considering when working with toPromise.
If the Observable completes but does not emit a value, the promise will resolve with undefined.
First of all, thank you for this question and answer, I wrongly assumed toPromise() knew what it was doing in all scenarios and would unsubscribe when that observable completes (even if it is an observable stream)
So I will just say that it doesn't hurt to pipe all of your observables before using .toPromise()
I just went through a big ordeal of stepping through our app for memory leaks and found the above answer by Will to be good. The elaboration on the actual question was exactly the same issue I was running into.
We are stepping through each observable in the app right now and we use either
pipe(take(1)) which is equivalent to pipe(first()).
or we use pipe(takeUntil(this.destroyed)) where this.destroyed.next(true) is called when we destroy our particular component or service.
We use take() to keep our verbiage consistent so we can search for take or takeUntil across various components.
Long story short, yeah you might take a very slight performance hit piping your observables at each instance, but I highly recommend doing so in order to prevent any unwanted app-wide memory leak hunts. Then maybe if you have the time you can step through each one and see where .toPromise() actually unsubscribes correctly for you.
I have a service that I want to hand out a Subject (although it could be typed as an observable) as the result of a method call. This is straightforward, but what I really want is to be able to "detect" when its unsubscribe method is called (or since it could technically be handed out more than once to multiple subscribers, when its subscription count falls to zero). Is this possible?
If you take a look at the source code to a behavior subject
https://github.com/ReactiveX/rxjs/blob/master/src/internal/BehaviorSubject.ts
you will see how to extend a subject. You could do the same thing to create your own kind of subject that instead of taking a start value it takes a callback to be run on unsubscribe that passes in the observer count. You would need to return a custom subscription object as unsubscribe is done from the subscription.
I was playing around with the switchMap operator to clearly understand what was happening to a "switched" inner observable.
At first i thought that switchMap was only "unsubscribing" from the switched inner observable, but then i realize it was in fact "unsubscribing AND completing" the inner observable.
To confirm that i've written this small snippet:
https://codesandbox.io/s/relaxed-meninsky-c5jmw?fontsize=14
As you can see, the finalize() operator is correctly called when the subject emit for the second time, but:
why does the complete handler of the tap operator is not called ?
This somehow make feel only 80% happy with my understanding of this operator.
A related not on that:
I've read and watch numerous sources regarding switchMap, including:
This (great) ngconf sources: https://medium.com/#shairez/a-super-ninja-trick-to-learn-rxjss-switchmap-mergemap-concatmap-and-exhaustmap-forever-88e178a75f1b
The official rxjs doc: https://rxjs-dev.firebaseapp.com/api/operators/switchMap
And none of them clearly state if inner observable is unsubscribed or unsubcribed AND closed ( or at least i did not understand it :) )
I've watched the switchMap operator source code and there is no mention to takeXXX operator, how can he complete the inner operator without that ?
tl;dr
Do you confirm that switchMap complete inner observable when switching ?
Why does tap operator does not work as expected ?
If switchMap effectively complete inner observable how can he do that without using a takeXXX operator internally ?
I think you are confusing the difference between unsubscribe() and complete(). For a hot observable like a Subject you can "stop" it in a few ways. From the 'top->down' with complete() as you did in your example, or from the 'bottom->up' with unsubscribe().
switchMap() does exactly what it says, it switches from the primary observable to a secondary (or 'inner') observable. That is why when you complete() the outer observable, it has no effect on the inner one - the chain has been switched. To affect the chain (as opposed to just affecting the Subject which is the source observable), you need to get a reference to the Subscriber, and then call that Subscriber's unsubscribe() method.
To see this, I've forked your CodeSandbox and produced this new one
As you will see in that CodeSandbox I have added a few more lines to show what is going on:
Note the new tap() in the chain right above the switchMap - this will show what is going on directly from the Subject() before the chain is switched to a different Observable with the switchMap operator.
The Subscription for the chain is now being captured in the variable sub which can be unsubscribed later to affect the chain from the bottom->up.
Note that the s.complete() after 10 seconds is now reflected in the Subject, and note also how it doesn't affect the chain at all.
Now note that the new sub.unsubscribe() after 15 seconds indeed kills the chain.
uncomment the take(5) in the newT() method to see that indeed the tap's complete method will be called if the source above it actually completes (top->down).
finalize() catches the fact that an unsubscribe has happened (bottom->up), note that it occurs both when switchMap() does the automatic unsubscribe upwards when s.next() is called on the Subject source, as well as when unsubscribe() is called on the Subscription, which again causes a bottom->up termination. In no case is your complete() called in the original observer because the chain is never actually completed. You can complete the chain with a take(10) operator if you want, to see how that works as well.
Hopefully this helps clear up the confusion a little. :)
So the case is this. Suppose somewhere I am filling a Collection. Each time an element is added, an IObservable calls OnNext for its subscribers.
Now, there will be a point where the collection will be filled. (I was reading something and I finished reading .. whatever). At that point, OnComplete() is called on the subscribers.
The user, however, won't observe this method. He will rather call an async method that he will await for ... he doesn't care much about the things he read, he just cares that he finished reading.
So basically, I want, from an IObservable, a Task that returns when the IObservable calls OnComplete() to its subscribers. I specifically want the user not to use an observer, but just to be happy with knowing that whatever happens after his await call will happen after the collection is filled.
Maybe the ToTask() method does the trick? I can't really tell by the documentation.
If you are using Rx 2.0 or later you can await IObservable which returns the last item in the observable. I.e. after the observable has completed.
var lastItem = await myObservable;
This is possible because in Rx 2.0 a GetAwaiter extension method on IObservable was added making it possible to await observables. There are also some handy extension methods that allow you to specify which element you want to await.
There is a nice blog about it here.
I'm trying to figure out how to handle events using coroutines (in Lua). I see that a common way of doing it seems to be creating wrapper functions that yield the current coroutine and then resume it when the thing you're waiting for has occured. That seems like a nice solution, but what about these problems? :
How do you wait for multiple events at the same time, and branch depending on which one comes first? Or should the program be redesigned to avoid such situations?
How to cancel the waiting after a certain period? The event loop can have timeout parameters in its socket send/receive wrappers, but what about custom events?
How do you trigger the coroutine to change its state from outside? For example, I would want a function that when called, would cause the coroutine to jump to a different step, or start waiting for a different event.
EDIT:
Currently I have a system where I register a coroutine with an event, and the coroutine gets resumed with the event name and info as parameters every time the event occurs. With this system, 1 and 2 are not issues, and 3 can solved by having the coro expect a special event name that makes it jump to the different step, and resuming it with that name as an arg. Also custom objects can have methods to register event handlers the same way.
I just wonder if this is considered the right way to use coroutines for event handling. For example, if I have a read event and a timer event (as a timeout for the read), and the read event happens first, I have to manually cancel the timer. It just doesn't seem to fit the sequential nature or handling events with coroutines.
How do you wait for multiple events at the same time, and branch depending on which one comes first?
If you need to use coroutines for this, rather than just a Lua function that you register (for example, if you have a function that does stuff, waits for an event, then does more stuff), then this is pretty simple. coroutine.yield will return all of the values passed to coroutine.resume when the coroutine is resumed.
So just pass the event, and let the script decide for itself if that's the one it's waiting for or not. Indeed, you could build a simple function to do this:
function WaitForEvents(...)
local events = {...}
assert(#... ~= 0, "You must pass at least one parameter")
do
RegisterForAnyEvent(coroutine.running()) --Registers the coroutine with the system, so that it will be resumed when an event is fired.
local event = coroutine.yield()
for i, testEvt in ipairs(events) do
if(event == testEvt) then
return
end
end
until(false)
end
This function will continue to yield until one of the events it is given has been fired. The loop assumes that RegisterForAnyEvent is temporary, registering the function for just one event, so you need to re-register every time an event is fired.
How to cancel the waiting after a certain period?
Put a counter in the above loop, and leave after a certain period of time. I'll leave that as an exercise for the reader; it all depends on how your application measures time.
How do you trigger the coroutine to change its state from outside?
You cannot magic a Lua function into a different "state". You can only call functions and have them return results. So if you want to skip around within some process, you must write your Lua function system to be able to be skippable.
How you do that is up to you. You could have each set of non-waiting commands be a separate Lua function. Or you could just design your wait states to be able to skip ahead. Or whatever.