reducer is not executed immediately and in order of calls to dispatch

[glennsl]

Calls to dispatch currently results in deferred execution of the reducer and does not guarantee that messages are processed in the order they were dispatched. This can cause subtle bugs when the reducer has side-effects that depend on ordering.

I understand the motivation for this is to have potentially blocking calls in the reducer not block the UI thread. As I understand it, the deferred execution of reducer is still run on the UI thread however, but even if it wasn't I think it would be better to have a separate mechanism for deferring side-effects and dispatching messages back to the reducer to update state. Similarly to how ReasonReact has the reducer return a variant Update | SideEffect, or how Elm has the update function return a tuple of the state and a Cmd.

I therefore propose first changing the reducer to execute immediately, but still have the rendering deferred, and then to consider a separate mechanism for async side-effects to be implemented later.

[wokalski]

I'm ok with reducers being called immediately but when we have some sort of scheduler I'd like to make it deferred again. i.e. don't rely on it being called immediately.

[glennsl]

I'm not sure there's any reason to make the change now then, unless there will also be a better mechanism for handling side-effects at that point.

But I think the more important issue to fix here is the order not being preserved. If it is preserved, then as long as all relevant side-effects are triggered in the reducer they'll also happen in the correct order.