> The idea of unidirectional dataflow is pretty good

Yes, but it's a bog standard local bus or message queue. There's nothing even slightly innovative about this approach.

Redux IS Flux.

Redux is "inspired by" Flux, but it's not Flux. One very big (and positive) difference: with Flux each store notifies the React components when it's updated, independently from the other stores.

This means that, if you update two stores with a single action, this will provoke two renders, the first one with inconsistent data between the two stores (in other words, there is no way to update all the stores atomically from the React components point of view).

Redux, instead, updates the whole store, and only then notifies the React components.

That's an important note, indeed. Flux is a pattern as well as a library that represents an implementation of the pattern. Redux is another implementation (and a better one at that, in my opinion.) Specifically regarding Greyrest's concerns about many changes across many files - this can be reduced substantially using Redux.

With all that said, I still wouldn't consider FluxJS a bad place to start, as it provides a very clear example of what Flux really is, but once you understand how the pattern works you'll understand where the implementation is lacking and how Redux can help with that.

My main issue with Redux is that it is incredibly verbose compared the alternatives.

Also one single state is great for simple-moderately complex apps but it gets horrible for ones not build from scratch to work with that dynamic.

Something like Alt I find to be the best of both worlds tbh.