What was there before Redux?

In 2011, Facebook had a big issue with its notification system; the problem was called Zombie Notifications. Users received chat notifications, but when they clicked on them, there would be no new messages waiting for them. The Facebook team was getting a lot of complaints about this issue, and after a lot of research, they found the problem: the entire architecture was weak and had been since its creation.

Facebook was using the MVC architecture at the time, which became increasingly unstable as the application grew more and more complex. Here's an example of a common MVC architecture:

Figure 1.2 – MVC architecture

Basically, the number of models, controllers, and views that shaped Facebook became unmanageable to maintain. That's why newer frameworks appeared in the frontend ecosystem, one of which was Backbone.js.

Backbone.js was one of the first popular MVC frameworks that went viral around 2015. It acts as a smart wrapper around JavaScript objects and arrays and includes a small pub-sub events system built into it. Pub-sub is a publisher-subscriber relationship where the publisher sends a message to a topic and it is immediately received by the subscriber. All models and collections automatically trigger events as data is changed.

Here is an example of Backbone.js architecture:

Figure 1.3 – Backbone.js architecture

We can compare Backbone.js with the MVC architecture in Figure 1.2 and see how much easier Backbone.js was compared to an MVC architecture, but there was still work ahead to improve even more the state management solutions.

In 2014, Flux was adopted early by many people and this new method of state management was approved by developers. One of the main concepts of Flux is that all data must flow in only one direction. When the data flow is always in the same direction, everything is super predictable.

As we saw in Figure 1.2, some views and models have arrows running in both directions, so the data flow is bidirectional. With Flux, the MVC diagram is reconsidered, as shown in Figure 1.4:

Figure 1.4 – Flux architecture

Let's briefly explain what the elements in each box mean.

Flux Actions

Actions are descriptions of the ways users can interact with the app. Basically, they are JavaScript objects, whose only requirement is to contain a required type field, although they do contain extra data used to fill the store.

Here is an example of a Flux action with the required type field and a payload object:

{
  "type": "ADD_TODO_ITEM",
  "payload": {
    "taskId": 1,
    "task": "Some task name"
  }
}

We use the type field to define what kind of change will be made to the app state, and payload is used for passing data to the store.

Flux Dispatcher

The Dispatcher function receives an action as an argument and forwards it to each of the application's stores. We have to remember that any Flux application with a solid pattern must only contain one dispatcher method.

To make it clear, we could say the dispatcher method is like a central interface between actions and stores. Basically, it is the magic wand that orchestrates actions and sends them directly to the store.

Here is an example of a Flux Dispatcher:

const countDispatcher = new CountDispatcher();
let countStore = {count:0}
countDispatcher.dispatch({ action: 'incrementCount' })
console.log(countStore)
// {count: 1}

This code is just an example of how a Flux dispatch function could be executed; the most common way is passing an object with the type that must match the reducer name. This is why we must think about dispatching actions such as triggering events – something happened, and we want the store to know about it.

Flux Stores

Stores contain the application state and logic. They are similar to a model in the MVC architecture.

A store registers itself with the dispatcher and provides it with a callback. This callback receives the action as a parameter, the store is subscribed to read any action that comes, and decides accordingly how to interpret that action. After the stores are updated, they broadcast an event declaring that their state has changed. In that way, the user interfaces can query the new state and repaint the screen correctly.

Basically, we have to understand that in order to modify our stores, we'll need to "dispatch" actions. Since all stores receive actions, a store will determine whether or not to modify its state upon receiving an action by looking at that action's type.

Views

Views (also called user interfaces) are what the user can see and interact with. They are the interfaces for displaying the data coming from our stores, as well as for sending actions back to the stores through the Dispatcher. Flux and Redux were designed to work with any frontend framework because there are bindings. A software binding refers to a mapping of one thing to another; it's like a wrapper to resolve the complexities of other libraries, but they were mainly designed to work with React.

For React there is a library called react-redux, a library for which you need to learn just one method for now: connect(). To be brief, because we'll explain this in detail in Chapter 5, React with Rematch – The Best Couple – Part I, connect() maps our Redux state to props on our React component. With this library, it becomes easier to integrate Redux into our React projects.

The following diagram depicts how React handles Redux subscriptions:

Figure 1.5 – React UI architecture with Redux

We can see the common architecture of Redux, but with the addition of a section called Link – this is where the react-redux connect() function makes the connection between React and Redux.

In this section, we learned how frontend technologies regarding state management evolved. We also learned how Flux works and why it was created, covering the main concepts to continue our journey with Redux. Now we are going to introduce and compare the main differences between Flux architecture and the refined way of Redux.