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.

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.