If anyone cares, by the way, actually having a Controller has done wonders for our code at TalkJS. Our View is purely React components, all of which only deal with presentation logic and local interaction logic. The components query the store (Model) for data, like in any Flux/Redux setup and like MVC has encouraged for decades.

Then, user actions are handled in the Controller. In our case it's just a bag of functions. The Controller fetches and pushes data from/to the backend, and sends appropriate actions to the store. This allows us to keep all the backend data fetching/manipulation logic out of the View, which keeps the View clearly focused on the UI and the UX, and nothing else.

Our controller does not have read access to the store: any data the controller functions need to do their work is passed in from the view (which has the data anyway because it used it to query the store appropriately).

This works great, it's total unidirectional data flow, it's also pure classic MVC, and I haven't seen anyone describe it elsewhere. We came up with it 2 years ago when React was pretty new and I had little else than MVC to be inspired by.

If you have data molding code all over your views (and a little bit elsewhere too, for good measure), consider a controller.