baconjs / bacon.js

Functional reactive programming library for TypeScript and JavaScript

Home Page:https://baconjs.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unexpected and inconsistent `holdWhen()` behavior

timmolendijk opened this issue · comments

In the API docs .holdWhen() is said to:

pauses and buffers the event stream if last event in valve is truthy

When I tried to reproduce this behavior I couldn't, and on top of that I found v0.7.60 to behave very differently from v0.7.59.

My code sample is as follows:

Bacon.fromBinder(function (sink) {
  sink(new Bacon.Initial());
  sink(new Bacon.Error());
  sink(new Bacon.Next());
  sink(new Bacon.End());
  return function () {};
}).holdWhen(
  Bacon.later(2000, false).startWith(true)
).subscribe(function (event) {
  $('#log').append(event.constructor.name + "\n");
});

The output in #log that I had been expecting:

<2 sec delay>
Initial
Error
Next
End

Instead, what I ended up getting:

The result under v0.7.59 (demo):

Error
<2 sec delay>
End

The result under v0.7.60 (demo):

Initial
Error
Next
End
<no delays at any point in time>

I did look into the corresponding unit tests, as those are succeeding, but I had a hard time replicating them as they depend on some factory methods (expectStreamTimings() and series()) which are unfamiliar to me.

Two questions:

  • What is the expected behavior of holdWhen() in the case of my code sample?
  • What explains the difference between v0.7.59 and v0.7.60 (and possibly the expected behavior)?

I'd say the expected behavior would be

Error
<2 sec delay>
Initial
Next End

Because the Error events are always passed through directly.

This is once again an issue with synchronous sources. If you delay the source, it'll work.

The difference to 0.7.59 is that holdWhen has been completely re-implemented.

It would make sense to fix this, of course.

Ok, fixed in 0.7.61, with 2 more test cases. Will you pls check if it works for you.

Works, except that the Initial has been transformed into a Next: demo

Thanks. Well, Initial is a corner case: EventStreams should never emit Initial events. It gets converted on the way... somewhere :)

Anyway, this seems to be fixed now. Please re-open if you disagree.

Yes, agree.

It does beg the question what to do with Initial events in general though, for which I opened a new issue #598.