Regarding next-action, in Redux subscribers are called after the root reducer returns the new state. You can always call dispatch from a subscriber.
You and Sam are proving my point by not actually taking the time to understand the existing solutions.
> in redux the reducer updates the model as: state.counter += 1 ;
That's not how Redux code would look, nor is that how Redux state works.
> you should write it as: [...]
That actually looks very much like how you'd actually write a reducer. Can you please clarify how you think this differs from idiomatic Redux code?
> Redux does not have any next-action-predicate
Inventing terms does not aid in advancing a discussion, especially if you do not define them. But reading through the OP, it appears that a next-action-predicate is just a selector, or possibly a selector used to implement what in Redux would be solved my middleware? The description is quite cryptic, but it at least claims to solve a problem which is already solved cleanly in Redux, which rather raises the question of what the advantage it yields is.
I mean this nicely, but: You're not really convincing me that SAM is a different pattern. Perhaps a simple example app? Ideally some small idiomatic redux todo app ported to SAM; that should show the differences (and benefits) very clearly.
In a nutshell:
in redux the reducer updates the model as: state.counter += 1 ;
All SAM suggests is that this is an unfortunate coupling, you should write it as: // action function increment(value) { return value + 1 ; }
and then present the output of the action to the model:
state.counter = data.counter ;
Redux does not have any next-action-predicate either.