-
Notifications
You must be signed in to change notification settings - Fork 331
-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flatMapLatest spawns next substream before the previous is disposed #783
Comments
One could also delegate this problem to user-land. For example, if there is this unwanted behaviour: var subStream = x => {
console.log(`Creating substream ${x}...`);
return B.fromBinder(sink => {
const interval = setInterval(sink, 1000, x);
return () => {
console.log(`disposing substream ${x}...`);
clearInterval(interval);
};
});
};
B.sequentially(2500, ["A", "B", "C"])
.flatMapLatest(subStream)
.take(7).onValue(console.log);
/*
Creating substream A...
A
A
Creating substream B... ↑ incorrect order
disposing substream A... ↓
B
B
Creating substream C... ↑ incorrect order
disposing substream B... ↓
C
C
disposing substream C...
C
*/ the user can enforce the correct order by delaying substream creation: var callNextTick = f => x => B.later(0, x).flatMap(f);
B.sequentially(2500, ["A", "B", "C"])
.flatMapLatest(callNextTick(subStream))
.take(7).onValue(console.log);
/*
Creating substream A...
A
A
disposing substream A...
Creating substream B...
B
B
disposing substream B...
Creating substream C...
C
C
disposing substream C...
C
*/ If this would be fixed in the library, problems with synchronous substreams (e.g. So either add a comment to the documentation of |
Sometimes
flatMapLatest(fn)
creates the substreamfn(x)
before the past substream got disposed.I did not expect this behaviour. When I used
tasks.flatMapLatest(sendTaskToWebWorkerAndWaitForCancellationOrResult)
to feed tasks into a single WebWorker thread, the webworker did sometimes receive a new task before the previous got cancelled.Also easy to reproduce using
fromArray
.The reason is that in the implementation, which is roughly
It is unclear if a new
x
value first cancels the previous substreamfn(x).takeUntil(obs)
or first callsfn(x)
to create the next substream.An implementation
might fix it.
However, I don't know if I am aware of all use cases. Otherwise I might attempt a PR.
Do you think it's worth fixing?
The text was updated successfully, but these errors were encountered: