In this way, it seems that React makes a lot of sense as a migration path. Honestly, I find flux/redux and other unidirectional data flows are much easier to scale than most patterns for UI development, especially class/oo ones.
That said, React is just a part of it, and some flows are counter-intuitive in React. This must be said because it is true... that said, I find that React is far better, all around than most of the other options I've used, and I've been building web apps for two decades now.
I'm currently working on supporting an Angular 1.x app, have a proof of concept built in Redux+React, and another app I've been instructed to write in Angular 2. I've also built a couple of SPAs using Backbone. In the end the Redux flow has meant less code as features are added, and I'm working towards writing my Angular 2 app with that in mind. Modern React takes a lot of tooling setup to get started (or starting with someone's existing boilerplate), but the shear amount of boilerplate code that you have to write with Angular2 is just unnerving. The DI model is awkward, and I'm not enjoying it at all...
The Redux+React proof of concept is for half the functionality of the Angular 1.x app, I'm pushing for the change in the next version... with about 1/3 the functionality, the code is 1/10th the size, and there's a lot less complexity... A single state tree, in the end is easier to reason with, even if you're only looking at part of it. It's much easier to deal with, even with scale than trying to add more message channels in an application between components. Getting used to separating actions via a single dispatcher, and the resulting state changes takes getting used to... but so much easier in the end.
Have you checked Elm? I know there is a big difference between switching frameworks and entire language, but the benefits are really nice. Elm really enforces unidirectional data flows throughout entire application. For me it's like react on steroids.
I've been using Redux, and it is pretty much required if you have multiple components who need to update when a single state changes.... but pretty unhappy as the amount of scafolding required. It's not nearly as "isolated concerns" as it should be.
Take a look at MobX. It's a different paradigm that requires very little boilerplate and results in more isolated components that react independently upon changes to state.
https://github.com/mobxjs/mobx
1. Elm. I was just about to throw away the idea of Flux in a web app till I saw TodoMVC implemented in Elm. In Elm everything is immutable, and as a functional language, it has a lot of helpful syntax to help you deal with immutability. Shoehorning immutability into Javascript seems to require a lot of scaffolding by comparison.
2. MobX, it's been mentioned elsewhere but I can't help but sing its praises. Writing in MobX means that using controllers/dispatchers/actions/supervisors or another form of managing dataflow returns to being an architectural concern you can pattern to your application's needs, rather than being something that's required by default for anything more than a Todo app.
I've got a list of some particularly good ones at https://github.com/markerikson/react-redux-links/blob/master... . There's also a link to a little "starter kit search engine" someone built that lets you filter about 50-60 of them by various attributes.
My anagram is r3k[1] (React, Redux, RethinkDB, Koa) ... Still a work in progress. Wanting to get to the point where I have an adaptive login (local account, google, facebook, twitter) and some public/private pages with universal rendering. Been working on it as time permits.
That said, React is just a part of it, and some flows are counter-intuitive in React. This must be said because it is true... that said, I find that React is far better, all around than most of the other options I've used, and I've been building web apps for two decades now.
I'm currently working on supporting an Angular 1.x app, have a proof of concept built in Redux+React, and another app I've been instructed to write in Angular 2. I've also built a couple of SPAs using Backbone. In the end the Redux flow has meant less code as features are added, and I'm working towards writing my Angular 2 app with that in mind. Modern React takes a lot of tooling setup to get started (or starting with someone's existing boilerplate), but the shear amount of boilerplate code that you have to write with Angular2 is just unnerving. The DI model is awkward, and I'm not enjoying it at all...
The Redux+React proof of concept is for half the functionality of the Angular 1.x app, I'm pushing for the change in the next version... with about 1/3 the functionality, the code is 1/10th the size, and there's a lot less complexity... A single state tree, in the end is easier to reason with, even if you're only looking at part of it. It's much easier to deal with, even with scale than trying to add more message channels in an application between components. Getting used to separating actions via a single dispatcher, and the resulting state changes takes getting used to... but so much easier in the end.