You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My superficial issue is to document explicitly that the side-effect f in observable.onValue(f) like observable.subscribe(f) has the ability to cancel its subscription of stream updates by returning Bacon.noMore.
After hours of debugging (see code example below) this really came as a surprise for me because I've never had an event consumer function to update the event flow logic. Up to now I did not care what my side-effects return: Promises, Strings or whatever...
Is this an API which is worth supporting? I mean:
Does this encourage good programming practise?
Can this break for innocent-looking side-effect functions? (E.g. returning a WebComponent tag which could be <no-more>, or the example below ?)
Breaking a stable API is bad but IMO this feature is dangerous.
What does everybody think?
Here my example of two nested Bacon.fromBinders. Can you spot why outerStream is unsubscribed even though nobody calls unsubscribe or returns Bacon.noMore explicitly?
varouterStream=Bacon.fromBinder(functionmyOuterBinder(sinkOutside){constinnerStream=Bacon.fromBinder(functionmyInnerBinder(sinkInside){// quasi sinking sinkInside into sinkOutsidesetTimeout(sinkOutside,2000,sinkInside);return()=>console.log("cleaning inner");});innerStream.take(1).onValue(x=>console.log("inner consumer",x));return()=>console.log("outer clean up");});outerStream.onValue(f=>f("inner value"));// f is sinkInside actually/* The output is:cleaning inner <-- OK because take(1)inner consumer inner value <-- OKouter clean up <--- THIS WAS A SURPISE! */
The solution begins with that sinkInside of the inner stream's binder returns Bacon.noMore because of take(1). This is then fed to the outer stream's .onValue() side-effect invoker by the ES6 arrow => function in the last line.
I could blame it on ES6 arrow functions because re-writing the side-effect to a "regular" function expression fixes the behaviour.
I've never used Bacon.noMore in a subscriber either. I think I've heard people using it somewhere though. I could imagine it being convenient for a "do this side effect and ignore future events if something specific happened while performing the side effect" case but personally I cannot recall ever feeling like doing that.
Would be great to hear if someone needs this feature. But seems like there's not so much interest in a conversation here :)
My superficial issue is to document explicitly that the side-effect
f
inobservable.onValue(f)
likeobservable.subscribe(f)
has the ability to cancel its subscription of stream updates by returningBacon.noMore
.After hours of debugging (see code example below) this really came as a surprise for me because I've never had an event consumer function to update the event flow logic. Up to now I did not care what my side-effects return: Promises, Strings or whatever...
Is this an API which is worth supporting? I mean:
<no-more>
, or the example below ?)Breaking a stable API is bad but IMO this feature is dangerous.
What does everybody think?
Here my example of two nested
Bacon.fromBinder
s. Can you spot whyouterStream
is unsubscribed even though nobody callsunsubscribe
or returnsBacon.noMore
explicitly?The solution begins with that
sinkInside
of the inner stream's binder returnsBacon.noMore
because oftake(1)
. This is then fed to the outer stream's.onValue()
side-effect invoker by the ES6 arrow=>
function in the last line.I could blame it on ES6 arrow functions because re-writing the side-effect to a "regular" function expression fixes the behaviour.
However, if someone comes along and refactors it back into an arrow function the bug reappears!
The text was updated successfully, but these errors were encountered: