Intro
Last week we delved into Flux and saw the benefits of having a unidirectional architecture. We also learned that there were multiple Flux implementations, each implementing Flux in slightly different ways to improve upon it.
This week I want to take a look at
Redux which takes Flux and improves it greatly making all sorts of cool things possible. Redux is the most
popular Flux implementation at the moment.
Redux
Redux takes Flux and improves on it, so what are the differences between Flux and Redux?
A single source of Truth
Flux has the concept of Stores, which represent a group of domain entities and the operations that can be performed on them. For example a CarStore would contain all 'car' objects and have operations to add and remove cars.
Each domain entity has their own Store. This means that the 'state' of the application, whilst having a clear location, is still located in multiple objects. Redux argues against this approach, Redux has a single Store for every entity. In other words the entire state of the application is stored inside a single variable.
This sounds a bit like a mad idea but it actually has benefits.