The first iteration of React JS was created by Facebook software engineer Jordan Walke in 2011. At the time it was called FaxJS and it set out to handle cascading updates as Facebook’s code base continued to grow. It was then deployed to Facebook’s newest acquisition Instagram in 2012 and made open source in May of 2013. At that point, everyone was free to utilize React’s helpful library to create better user interfaces on their applications.
However, React was not created as an end all be all application framework. Accessing an applications backend or local storage can be overly intensive while using React due to the nature of its Flux architecture. Flux architecture was created by the Facebook development team as an alternative to Model View Controller architecture commonly used in application design. MVC’s back and forth nature (View sends a request to the Controller, the Controller sends the request to the Model for logic, the Model sends the result back to the Controller to then be rendered again by the View) becomes complicated as an application grows in size because each database record (e.g. a user’s authentication info, their photos, their comments, etc.) tends to have its own MVC structure. For the most part, these structures will then work independently of each other as the application runs resulting in a constantly changing decentralized “state” of each database record.
To avoid this bidirectional, decentralized data flow in their React framework, the developers at Facebook set out to create a structure of unidirectional flow of information via Flux architecture. Flux architecture handles a similar user request by having the View (React Component) create an Action. The result of this Action is then Dispatched to the related Store where the state is updated for the View to re-render. Because the data flows through the application in a single direction the developer can have better control over it. The structure does provide more centralized data than MVC, but the state information is still spread across multiple stores throughout an application.
In 2015 another Facebook engineer Dan Abramov determined the Flux architecture could be even more streamlined and created the first rendition of React Redux. In an interview with UI.dev, Abramov said “I was trying to make a proof of concept of Flux where I could change the logic. And it would let me time travel. And it would let me reapply the future actions on the code change.”
With the help of yet another Facebook software engineer (Andrew Clark), the React Redux was released for public use. The most noteworthy aspect of their new library was the single, centralized Store. This Store maintains the application’s entire state, so that it is readable and writable throughout the entire application. This proves beneficial as it ensures data consistency and continuity between application Views (React Components). The other important feature of React Redux is the Reducer. The Reducer is a function that handles all front-end business logic by taking in the application’s previous state and an action which updates and returns a new state. So, in a request similar to the ones above, the centralized Store maintains an internal state variable. The View creates an Action which is dispatched to the Reducer, and the Store replaces its internal state variable with whatever the Reducer returned.
Choosing the best design architecture is an important part of developing an application. The three options mentioned above can prove beneficial in different ways depending on the goals of the project.