Written by on 26 October 2015

Redux: Flux evolved

If you have been reading a bit about React, you probably also saw the name “Flux” come up every now and again. Flux is a unidirectional data flow pattern, and the pattern Facebook created and advises to use with React. You subscribe to a store – which is sort of like a model – and simply react to changes in its state. When you want to change something, you send this request through a central dispatcher, that notifies interested stores. This kind of reactive programming is total hotness in JavaScript-land right now and makes creating complex user interfaces a lot less complicated.

flux pattern explained

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:

Hot reloading
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.

The horizon

The development of new libraries doesn’t end here or now. In the time we started working with Redux, already several other great alternatives popped up. Facebook recently released Relay and GraphQL. And if you want to go full-out reactive, Cycle.js is a great library to take a look at. We however, will keep working with Redux, for it suits our needs extremely well. It’s a dynamic and exciting time for anybody involved with JavaScript!

COMMENTGive your two cents.