[iotscale]

Correct me if I'm wrong but I think what you have is described as an "action dispatcher" these days.

For what it's worth, I think, we can define the whole Flux architecture in somewhat-skewed MVC terms. Not trying to downplay the usefulness of Flux here but if I'm not all wrong, it would've helped many people if we kept at least some of the terms from MVC or MVVM.

[skrebbel]

Ah cool, thanks. Does the action dispatcher also interact with the backend? My understanding was that it just created little action objects and little more. Our controller is decidedly more heavy-weight. I'm not saying it's the best possible way to go but it's been working well for us so far :-)

[Sacho]

In redux terms, your controller would be the bundle of "action creators". If you use vanilla redux, those would conduct all your "logic", including communicating with the backend. This has some pros and cons, so there are extensions("middlewares") to redux which iterate on the concept - redux-thunk, redux-saga, etc.

Since redux largely defines the design of the "Model" part and React largely defines the design of the "View" part, most of the variation when using React and redux is how to design your "Controller".

[Swennemans]

It is indeed very close to how you would model redux apps. Interesting that you mention that your controllers don't have read access to store(s). That is actually very common with redux-thunk or redux-saga.

[iotscale]

AFAIK it doesn't, but I'm just learning. My understanding is the standard way of doing things work if you are creating the most boring CRUD apps but you need to "bend the rules" a bit to make it work for your use case very often - as long as you keep it newcomer-friendly.