Strange behaviour for subscriber notifications

[mattiasgronlund]

According to the documentation, subscribe(listener) should:

Adds a change listener. It will be called any time an action is dispatched, and some part of the state tree may potentially have changed. You may then call getState() to read the current state tree inside the callback.

Then one would assume notifications are actually delivered when getState() returns the state which was the result of the action dispatched.

But the current implementation of dispatch, actually lets a new action be dispatched, before all listeners are notified (if the action was dispatched by one of the listeners).

Therefore some listeners will get the notification of the second action, before the notification for the first action, but both with the latest state.

The current behavior makes the state.dirtyHandlerIds optimization in dnd-core end up missing updates to state.dragOperation.

When listeners do optimizations like dnd-core, will that not break the time travel in redux-devtool?

If the behavior is intentional, I think it should be documented, and the code should probably be optimized so that the new state is only notified once.

[gaearon]

Good point. Can you raise this as an issue in dnd-core? The behavior is intentional; subscribers aren't guaranteed to get every state update, just the most recent one. If you have ideas how to optimize this please send a PR!

[mattiasgronlund]

I have create a PR for documentation clarification.
I guess it would be possible to make sure that the listener is not called again with the same state.
It would be trivial if we added the non simplified fix for #1180 (slorber@ea8091b), as:

     listeners.forEach(listener => {
-        if ( typeof listener !== 'undefined' ) {
+        if ( isDispatchingToListeners && typeof listener !== 'undefined' ) {
          listener()
        }

Would fix it.

But I agree with slorber that the non verified performance optimization is not worth the cost in code readability.