I think the idea behind Flux/unidirectional data flow is actually simple and is a natural way to manage shared state between view components. But the original description/implementation from Facebook made it more complex than necessary, which is why there came so many different flavors of flux implementations.
The primary problem that Flux solves is shared state. Without a mechanism to hold shared state, we naturally tend to store state inside view components. We would then often find state being scattered across view components and resort to two-way binding or cross-component communication to synchronize the state between components. The problem with that these synchronization attempts makes reasoning about state changes very hard. With Flux, because the only way to affect shared state is by dispatching actions, this ensures all changes to the state are trackable, thus making the data flow much easier to understand.
Notice that the above explanation has nothing to do with what view layer you are using. The same principles can be applied equally well to both React and Vue (or any other declarative view layers). For example, it's possible to use Redux with Vue via simple bindings such as revue. But in fact Vue now has its own Flux-inspired state management solution, Vuex.
Vuex is heavily inspired by Redux, but with some design tradeoffs to focus on simplicity and compatibility with Vue. It's also hot-reloadable, and supports time-travel debugging via vue-devtools, and it takes full advantage of Vue's reactivity system to ensure the performance is optimized by default.
Reply to this…