How We Got To Redux (for people who blinked)

As we scramble to assemble our stacks of packages, routers, stylers, store persisters and the like, it’s worth it to take a moment  to breathe, look around and get a bit of perspective on what exactly it is that we’re doing and why we’re doing it. I’ll let you get back to trying to make thunk work in a second, but for right now we’re gonna look back, waaaaay back to the dark ages of 1994.

The darkness was rend in twain by the publishing of the book Design Patterns: Elements of Reusable Object-Oriented Software. The work was one of the first comprehensive collections of the development patterns  that programmers had discovered and re-discovered over the preceding decades. Among the patterns described was one called The Observer Pattern. The gist of it is that you have an object called the observer that contains all of your state. An app’s ‘state’ is just its memory of any events that have occurred or user interactions that have taken place. In many patterns, state ends up scattered all over the app, in a million different variables. In the Observer Pattern, however, your state is contained in one big object. It has listeners on it that connect to all the dynamic parts of your app. If a certain part of your state changes, so does the element connected by the listener.

Facebook first made React public in 2011 and open-sourced it in 2013. It was created by Jordan Walke. Despite the way we think of it now, React wasn’t just a vehicle to give us all Redux. At an F8 session in 2014, Tom Occhino, the Engineering Manager at Facebook, gave a talk where he outlined problems Facebook had encountered with the standard MVC application architecture, and announced something called Flux.

Flux was a design pattern, and architecture. It was not an actual product that Facebook had built, it was simply a way of doing things that had allowed Facebook to dramatically cut down on bugs and made their codebase easier to work on without fear of breaking things. As people outside Facebook began wanting to write in Flux as well, demand grew for a framework, an implementation of the Flux pattern. Facebook released a dispatch method and left it at that. Fluxify was written, as was Reflux.

Dan Abramov, while trying to work in Flux was growing frustrated. Not only did the existing implementations not suit his needs, he wanted hot reloading. On top of that, he had realized that using pure object actions with reducers on a pure object store would enable time-travel debugging, replaying an app’s change in state over time. On May 29 2015, he tweeted “Oh no am I really writing my own Flux library” and Redux, from “Reducer” and “Flux” was born.

In 2015, Abramov gave a presentation at React Europe that showed a workflow with hot reloading and time travel debugging, made possible with Redux. Since then, the React-Redux ecosystem has only grown, with packages for routing, styling, and much more becoming part of the React developer’s toolkit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s