Non obvious behavior with `concat`, `Promise` and `EventEmitter`.

Hello.

Using xstream on a new project is my only experience with reactive programming so far. Therefore please excuse any obvious problems or mistakes.

I encountered a strange problem with this snippet:

concat(xs.fromPromise(somePromise), fromEvent(someEvent, 'test'));

My expectation was that concat would buffer the test events until the promise resolves (kind of like flattenSequentially. But the events are dropped altogether. I wrote two tests to expose this problem: https://github.com/kaukas/xstream/commit/6e693896c72fda4143d607e2b3996797fb822d62. Could you please let me know if this is expected behavior?

Thank you!

[kaukas]

Hello, @staltz.

I’ve been playing further with this. I am not sure how concat should behave but flattenSequentially is definitely not doing the right thing. Even in the case where the event is sent after the promise resolves the event is lost.

I suspect the reason for the lost events is that the fromEvents stream is only activated after the previous stream (promise) completes. Therefore all prior events are lost. Instead the fromEvents stream should be activated immediately on flattenSequentially call so that all subsequent events could be buffered. At least this is my opinion.

Thank you!

[webmaster128]

I’m implementing a version of buffering concat right now for my project.

This is a test case that shows the difference between the two versions of concat:

  it("buffers asynchonous events of second stream until first stream completes", done => {
    const sourceStream = Stream.periodic(25);
    const stream1 = sourceStream.take(3);
    const stream2 = sourceStream.take(3);
    const concatenatedStream = concat(stream1, stream2);
    const expected = [0, 1, 2, 0, 1, 2];

    concatenatedStream.addListener({
      next: value => expect(value).toEqual(expected.shift()!),
      complete: () => {
        expect(expected.length).toEqual(0);
        done();
      },
      error: done.fail,
    });
  });

• For buffering concat (see diagram above) it passes
• For xstream concat it produces [0, 1, 2, 3, 4, 5] instead of [0, 1, 2, 0, 1, 2]

The buffering concat behaves like

--1--2---3---4-|
-a--b-c--d-|
--------X---------Y---------Z-
          concat
--1--2---3---4-abcdXY-------Z-

wheras xstream concat behaves like

--1--2---3---4-|
...............--a-b-c--d-|
          concat
--1--2---3---4---a-b-c--d-|

As far as I can see xstream does what it documents. Hard to say what users expect.