far past that. The discussion is now, what framework do we build react apps with. And if you're answer is Flux, you're wrong.
If you stick all your data into a single big tree/store, you can inspect/serialize and pull off tricks like snapshotting, session recording, simple undo/redo, and time travelling debugging. I do my day to day development in clojurescript (re-frame) so I'm not necessarily up to date but I believe Redux is currently on top for doing this pattern in javascript land.
Yes, but it's a bog standard local bus or message queue. There's nothing even slightly innovative about this approach.
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.
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.
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.