I don't know why we keep doing it but often times we cover our eyes on purpose and brush off existing solutions backed by thousands of engineers so that it's easier to make our points.
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.
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.