It is a great concept and prevents a lot of the common issues you can have with MV* patterns, where the communication between elements of your application can go either way. This can become extremely hard to maintain after a longer period of time, when your application grows.
Redux takes this pattern one step further and in some miracle feat, it both adds functionality and reduces boilerplate. So what does it change about the already popular Flux pattern?
Dan Abramov, the creator of Redux, loves Flux, but wanted to improve the options for developer tooling. Especially hot reloading (replacing parts of your code in real time, without refreshing or even losing state) and advanced logging functionality for the state of your application. In my previous blogpost about Webpack I already showed a great video of Dan Abramov showing this in action, but in case you missed it, here it is again: Hot Reloading with Time Travel
A single store to rule them all
A normal Flux implementation will have numerous stores holding their own domain of data and state. One of the main changes Dan applied in Redux is implementing a single central store. You connect to a part of this big store through the use of reducers. These reducers that you write decide how to handle a specific action and apply a new state.
An important part of this is that the store’s state is never mutated. It is only copied and the new version is returned. This brings us to an important upside, namely that you can keep record of the transition of state and effectively time travel through your application. Needless to say this makes debugging your application a lot easier!
But wait, there is more:
It also makes it possible to hot reload the store code. Where normally you would lose all state when you replace the store, with Redux the logic is separated from the state by the reducers. This makes it effectively possible to replace all the logic in real time, without losing any of the state of your app!
Bye bye dispatcher
Because there is a single store, it makes no sense anymore to have a separate dispatcher. So the dispatcher was integrated in the store. Another concept less to think about.
All actions end up at the central store, so you can also apply a centralised way of passing through actions. This introduces the option to apply middleware, which makes it possible to add anything from simple logging functionality to custom action handling, for example for asynchronous actions.