Do You Need Redux in Your App?

Not long ago, web-applications were written purely on the server-side. All the heavy weight-lifting was done by the server. The only purpose of the client was to render the generated HTML/CSS and occasionally send a XMLHttpRequest to track some variables.

Eventually, with the surge in JavaScript libraries, like jQuery, and constant push from the community, browsers started competing on performance. This led to an unprecedented growth in front-end engineering techniques.

Entire websites were being written in JavaScript, servers started supporting JS (Node.js), and there was a push for isomorphic web applications.

Around 2013, the first version of React was released. It eventually became the most popular front-end framework of choice for thousands of developers in hundreds of companies.

As the complexity of web apps increased, many side-effects popped up. Occasionally a developer would forget to bind the correct listener or would trigger the wrong listener — the entire application state was a mess.

Enter, Redux.

Redux is an implementation of Flux. A set of patterns that Facebook followed for its own applications.

It has three principles:

1. Has a single source of truth — all information that the application reads should come from this object. We could call this object, the Store.
2. The Store should be read only — i.e. the application can only read data from the Store.
3. Any modification to the Store should be done by Pure Functions.

Let us take a break and understand what Pure Functions are.

Consider an adder, which takes two variables and returns the sum. This function would return the same value X if the inputs are A and B. In no condition would the function return a different value. Such functions are pure.

An example of a function that is not pure would be a Math.random in JS. It returns a different value every time.

Another rule for pure functions is that they should not try to modify either input parameters. They can only use the inputs to generate a new value and not modify/read from any other value. (e.g. a value from the Global Scope should not be read/modified during execution)

Getting back to Redux, when we apply the above three principles, we essentially remove a lot of uncertainities and complexities from our application.

Any modification to the application state can be guaranteed to have the expected behaviour, and all other dependent components could now read the new value of the Store (we can automate listening to every change by subscribing to the store for updates, more on this later.)

These pure functions are called Reducers. They receive Actions and previous state of the Store, and return the next state. For all practical purposes, the previous state is treated as Immutable.

Actions are objects with a type property set on them and any additional information that the reducer might need with respect to that action. For example, an action for Add_Todo would include the new todo object, which needs to be added to the Store.

Actions are created inside Dispatchers. Dispatchers could potentially do asynchronous tasks like IO or network calls before they dispatch the action or even between two actions.

Dispatchers can directly be invoked from the UI on user interaction or pre-defined intervals.

Hope you have a better theoretical understanding of Redux now. Feel free to reach out to me if you want to get on a call and get your hands dirty with some code.