Especially considering his proposed solutions looks an awfully lot like not-very-fleshed-out remakes of React and Redux.

This is not true, please visit the SAM room on Gitter https://gitter.im/jdubray/sam

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.

That's not true either. In Redux the reducer is always pure and never modifies its arguments, at least in principle. It returns a new copy representing the new state. Dan Ahramov relies on deep-freeze to always assert this fact in all of his tutorials.

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.

I'm extremely open to finding a better solution to React/Redux, but your example makes very little sense.

> 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.

Take a look at this boilerplate project (https://github.com/erikras/react-redux-universal-hot-example)... I think Redux with the multireducer lib removes that coupling you speak of.