events from fromEvent + scan out of order

I have the following code:

var createStore = function(name, reducer, initialState) {
  var storeName = 'store:'+ name

  var stream = most.fromEvent(storeName, document)
    .scan(function(state, event) {
      return reducer(state, event.detail)
    }, initialState)

  var subscribe = function(callback) {
    stream.subscribe({
      next: callback
    })
  }

  var dispatch = function(action) {
    document.dispatchEvent(new CustomEvent(storeName, { detail: action }))
  }

  return {
    stream: stream,
    subscribe: subscribe,
    dispatch: dispatch
  }
}


var store = createStore('foo', function(state, action) {
  switch (action.type) {
    case 'SET_FOOBAR':
      return { foobar: state.foobar + action.foobar }
    default:
      return state
  }
}, { foobar: 1 })

store.subscribe(console.log)
store.dispatch({ type: 'SET_FOOBAR', foobar: 3 })
store.dispatch({ type: 'SET_FOOBAR', foobar: 5 })

which strangely enough prints the initial state as the last thing to the console:

Object {foobar: 4}
Object {foobar: 9}
Object {foobar: 1}

I would expect it to print the inital state as the first thing, like this:

Object {foobar: 1}
Object {foobar: 4}
Object {foobar: 9}

is this a bug? I’m trying this on 1.7.0. I’ve tried this code with rxjs and xstream and they both work like I expected it to

[Risto-Stevcev]

@ryanlaws DOMHighResTimeStamp is in ms not mcs, could also be that you included the function declaration by accident:

const f = () => 123
const timeout = () => { performance.mark('fn-start'); setTimeout(f, 0); performance.mark('fn-end') }
timeout()
performance.measure('fn', 'fn-start', 'fn-end')
performance.getEntriesByName('fn')[0].duration
// vs
timeout2 = () => { performance.mark('fn2-start'); f(); performance.mark('fn2-end') } 
timeout2()
performance.measure('fn2', 'fn2-start', 'fn2-end')
performance.getEntriesByName('fn2')[0].duration

On my machine the difference is about 0.06-0.08 ms, which is 60-80 microseconds. That’s very negligible

[Frikki]

As I see it, @axefrog, the culprit is what @davidchase wrote here, and is aligning with your comment, too.

@Risto-Stevcev, I still think that most.scan() does what it should, but the dispatchEvent() call blocks the caller and messes up the order:

… the event handlers run on a nested callstack: they block the caller until they complete …

If we, as @TylorS mentions in his comment, didn’t ensure that events occur on a different callstack than the subscription, we would see race condition issues in many cases.

This relates to this issue, and the solution chosen was to develop @most/core and get rid of these not-really-true-event-streams (see @TylorS’s and @briancavalier’s comments towards the end of the issue).