What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about, model, and simulate than 2-way data flow. Everything else is semantics.
Instead they kept things simple and low level, to the point that writing vanilla React and Flux is kind of verbose. However, I much prefer this approach to some of the other frameworks that try to do everything for me, but which mostly just end up confusing me with too many abstractions.
It makes some things a whole lot "easier to reason about" (so sick of that phrase), but other things not so "easy to reason about", like, for instance, error handling. Getting my head wrapped around the fact that asynchronous errors had to live in their own stores and be handled in the same way as all other data passed to the view was certainly not "easy" to reason about and still doesn't sit right with me to this day. You make concessions with every pattern and there is no silver bullet.
- What is the current state of things?
- How did we arrive at the current state of things?
- What should the UI look like given the current state of things?
It means that we can say: "Thing A happened, then Thing B happened, then Thing C happened". And then conceptualize "what should things look like after that chain of events". I've found this to make errors a whole lot easier about, because I don't need to piece together the state when an error happens -- just fire an action that says "An Error happened", then the stores figure out how to act accordingly. It's just another action.
Unidirectional data flow has been mainstream at least as often as nests of observers and component state. Probably moreso, if you count the 20 years of computing where the only thing you could do was batch processing.
What React does do is bring unidirectional data flow into the modern SPA web era. That's an accomplishment now, but it's important to put it in its proper place in history. Most of the history of programming had unidirectional data flow, it has its share of flaws as interfaces get more complex and interactive, and it's likely that at some point in the future people will move back towards multidirectional data flow.
Win32 is not unidirectional data flow. there is the API SetWindowLong to modify/update a component anywhere you like. It's used so widely everyone must've done it.