JS中的反应流如何工作？

Question

I'm novice in reactive streams and now trying to understand them. The idea looks pretty clear and simple, but on practice I can't understand what's really going on there.

For now I'm playing with most.js , trying to implement a simple dispatcher. The scan method seems to be exactly what I need for this.

My code:

var dispatch;
// expose method for pushing events to stream:
var events = require("most").create(add => dispatch = add); 
// initialize stream, so callback in `create` above is actually called
events.drain();

events.observe(v => console.log("new event", v));

dispatch(1);

var scaner = events.scan(
  (state, patch) => {
    console.log("scaner", patch);
    // update state here
    return state;
  },
  { foo: 0 }
);

scaner.observe(v => console.log("scaner state", v));

dispatch(2);

As I understand, the first observer should be called twice (once per event), and scaner callback and second observer – once each (because they were added after triggering first event).

On practice, however, console shows this:

new event 1
new event 2
scaner state { foo: 0 }

Scaner is never called, no matter how much events I push in stream.

But if I remove first dispatch call (before creating scaner), everything works just as I expected.

Why is this? I'm reading docs, reading articles, but so far didn't found anything even similar to this problem. Where am I wrong in my suggestions?

Answer 1

Most probably, you have studied examples like this from the API :

most.from(['a', 'b', 'c', 'd'])
    .scan(function(string, letter) {
         return string + letter;
        }, '')
    .forEach(console.log.bind(console));

They are suggesting a step-by-step execution like this:

1. Get an array ['a', 'b', 'c', 'd'] and feed its values into the stream.
2. The values fed are transformed by scan() .
3. ... and consumed by forEach() .

But this is not entirely true. This is why your code doesn't work.

Here in the most.js source code, you see at line 1340 ff.:

exports.from = from;

function from(a) {
    if(Array.isArray(a) || isArrayLike(a)) {
        return fromArray(a);
    }  
...

So from() is forwarding to some fromArray() . Then, fromArray() (below in the code) is creating a new Stream :

...
function fromArray (a) {
    return new Stream(new ArraySource(a));
}
...

If you follow through, you will come from Stream to sink.event(0, array[i]); , having 0 for timeout millis. There is no setTimeout in the code, but if you search the code further for .event = function , you will find a lot of additional code that uncovers more. Specially, around line 4692 there is the Scheduler with delay() and timestamps.

To sum it up: the array in the example above is fed into the stream asynchronously, after some time, even if the time seems to be 0 millis.

Which means you have to assume that somehow, the stream is first built, and then used. Even if the program code doesn't look that way. But hey, isn't it always the target to hide complexity :-) ?

Now you can check this with your own code. Here is a fiddle based on your snippet:

https://jsfiddle.net/aak18y0m/1/

Look at your dispatch() calls in the fiddle. I have wrapped them with setTimeout() :

setTimeout( function() { dispatch( 1 /* or 2 */); }, 0);

By doing so, I force them also to be asynchronous calls, like the array values in the example actually are.

In order to run the fiddle, you need to open the browser debugger (to see the console) and then press the run button above. The console output shows that your scanner is now called three times:

doc ready
(index):61 Most loaded: [object Object]
(index):82 scanner state Object {foo: 0}
(index):75 scanner! 1
(index):82 scanner state Object {foo: 0}
(index):75 scanner! 2
(index):82 scanner state Object {foo: 0}

First for drain() , then for each event.

You can also reach a valid result (but it's not the same behind scenes) if you use dispatch() synchronously, having them added at the end, after JavaScript was able to build the whole stream. Just uncomment the lines after // Alternative solution , run again and watch the result.

Answer 2

Well, my question appears to be not so general as it sounds. It's just a lib-specific one.

First – approach from topic is not valid for most.js . They argue to 'take a declarative, rather than imperative, approach'.

Second – I tried Kefir.js lib, and with it code from topic works perfect. Just works. Even more, the same approach which is not supported in most.js , is explicitly recommended for Kefir.js .

So, the problem is in a particular lib implementation, not in my head.