Redux and Universal JS: observations, and how it’s changed my programming style

In 2016, the year of JavaScript fatigue, there’s still a lot to be learned by trying out some of the technology being peddled on Hacker News.

Redux is a simplistic Flux architecture that encourages you to carefully think about how you structure the domains within your application, forces the concept of immutable data within your application’s state, and also strongly encourages you to understand function purity.

As a beginner, I found the EggHead videos an incredible resource. The documentation and wider community discussion is overwhelming at first because you’ve got very smart guys talking about purity, arity, ramda, bacon, and reducing. You would be forgiven for thinking that arity and ramda were spices and most threads were just a continuation of a really ironic discussion about making some weird, pig based soup.

The terminology is confusing, but it doesn’t need to be. As a sufferer of imposter syndrome and nasty bouts of anxiety despite over 10 years in the game, trust me, if you haven’t already, you’ll quickly pick it all up and realise that it’s not rocket science after all.

Comedy and ignorance aside — why is Redux and some trivial knowledge of functional programming awesome? I believe that it has a notable, positive effect on code quality, readability, and rewards you with a huge reduction (or Reduxion!) in bugs.

Function purity

A pure function is one that provides the same result every time, if you give it the same arguments. Therefore, in practical JavaScript terms:

• if your function relies solely on the contents of its arguments — and not closure variables, globals, or any shared state — it’s pure.
• if your function relies on the current date and time, simply invert control and pass it in as an argument to ensure it remains pure.

Why is pure awesome? It forces you to split huge hunks of code in to smaller, testable functions with a defined purpose. It’s hardly a groundbreaking idea and it’s been preached for years, but function purity is a great way to explain it to teammates, and remind yourself to take your own advice.

Reducers owning branches of state and their selectors

If done right, I believe that you’ll end up with a nice public API for accessing that reducer’s domain, and a robust reducer that handles the more complex (and potentially ugly) parts of storing your state.

Accessing your reducer’s state via selectors, as opposed to doing so by directly referencing the state branch, means you get a powerful single point of reference, and a clearly named function for the rest of your teammates to understand.

A key thing I’ve found myself needing to remember is that it’s totally fine to have a reducer that handles multiple entities. They are essentially smarter handlers of models — which, strictly speaking, are composed of one or more entity.

Universal JavaScript

When reviewing my current project’s architecture, I started to understand that it is no longer the case that “frontend” developers have a limited scope as far as data management and “app smarts” goes. The majority of the app logic now sits within the UI’s reducers and selectors, while the app actions fetch the data from our API in a particular shape and marshall actions to ensure everything flows smoothly. The coupling is still there, but it does seem to lend itself to having “backend” guys work on delivering information faster. This is both a good and bad thing, to be discussed later, perhaps…

For all its rough edges, such as issues with Webpack’s loaders working on the server, the benefits of universal JS like page delivery speed and obligation to write your app logic once mean that it’s here to stay — and I believe that it’s only going to get better.