Understanding the Flux fundamentals

Flux is a pattern for managing data flow in your application, and it is the application architecture that Facebook uses for building its web applications. The following diagram shows the structure and data flow in Flux:

Figure 1.4: Structure and data flow in Flux

As shown in the preceding figure, Flux is divided into four parts, and data flows in only one direction. In the next sections, we will see how data flows through the following parts:

• Actions
• Dispatchers
• Stores
• Views

Although it is important to understand how Flux works, Vuex has its own implementation of Flux architecture that differs from Flux, and it will be explained in detail in the following chapters.

Actions

Actions define the internal API of your application. They represent what can be done, but not how it is done. The logic of state mutation is contained inside stores. An action is simply an object with a type and some data.

Actions should be meaningful to the reader and they should avoid implementation details. For example, remove-product-from-cart is better than splitting it into update-server-cart, refresh-cart-list, and update-money-total.

An action is dispatched to all the stores and it can cause more than one store to update. So dispatching an action will result in one or more stores executing the corresponding action handler.

For example, when a user taps on the Remove from cart button, a remove-product-from-cart action is dispatched:

{type: 'remove-product-from-cart', productID: '21'}

In Vuex, the action system is a bit different, and it splits Flux actions into two concepts:

• Actions
• Mutations

Actions represent a behavior of an application, something that the application must do. The result of an action consists typically of one or more mutations being committed. Committing a mutation means executing its associated handler. It is not possible to change the Vuex state directly inside an action; instead, actions commit mutations.

You have to deal with asynchronous code inside actions, since mutations must be synchronous.

Mutations, on the other hand, can and do modify the application state. They represent the application logic directly connected to the application state. Mutations should be simple, since complex behavior should be handled by actions.

Since there is only one store in Vuex, actions are dispatched using the store, and there is a direct connection between an action and its handler. In Flux, on the other hand, every store knows what to do when responding to the action.

You will read about the Vuex action/mutation system in the following chapters. Right now, you just need to understand the concepts behind actions, and that Vuex implements actions in a slightly different way than the one used by Flux.

Dispatcher

There is only one dispatcher per application, and it receives actions and dispatches them to the stores. Every store receives every action. It is a simple mechanism to dispatch actions, and it can handle dependencies between stores by dispatching actions to the stores in a specific order.

For example:

1. A user taps on the Add to cart button
2. The view captures this event and dispatches an add-to-cart action
3. Every store receives this action

Since Vuex differs from Flux because the dispatcher is inside the store, what you should remember here is that every change in the application begins by dispatching an action.

Stores

Stores contain the application state and logic. Stores can be mutated only by actions and do not expose any setter method. There can be more than one store in Flux, each one representing a domain within the application. In Vuex, there is only one store, and its state is called a single state tree. Vuex is not the only framework that enforces the use of a single store: Redux explicitly states that there is one store per Redux application. You may think that a single store may break modularity. We will see later how modularity works on Vuex.

Before switching to Flux architecture, Facebook chat kept experiencing a bug where the number of unread messages was wrong. Instead of having two lists—one of read messages and another of unread ones—they used to derive the number of unread messages from other components events. It is indeed better to have an explicit state where all the information is stored. Think of the state as an application snapshot: You could save it before the application page gets closed and restore it when the application gets opened again so that the user will find the application in the same state it was left in.

There are three important concepts regarding stores:

• Stores can be mutated only by actions
• Once a store is mutated, it notifies it has changed to the views
• Stores represent explicit data, as opposed to deriving data from events

Here is an example of a store reacting to the add-to-cart action dispatched in the previous example:

1. The store receives the add-to-cart action
2. It decides it is relevant and executes the logic of the action by adding the current product to the cart product list
3. It updates its data and then notifies the views that it has changed

Views

Views, or view controllers, display data from the stores. Here is where a framework like Vue.js plugs in.

Rendering data in the stores

In the Facebook video introducing Flux, software engineer Jing Chen talks about some of the problems they faced while developing Facebook Chat, and what lessons they learned. One interesting lesson they learned concerns rendering: They didn't want to rerender all the messages in the chat, but instead wanted to optimize it a bit by updating the chat view with only the new messages. If you are an experienced programmer, you may think, This is a premature optimization. Indeed it is! It is much more simple to pass the whole view-model to the views rather than just pass the differences from the old and new model.

Say that a programmer wants to add a new feature to a view: If the view-model is rendered by the view each time it is modified, they just need to add some properties to the model and add some code to the view to display these new properties. They don't need to worry about updating/rendering logic.

But what about performance? Isn't it bad to rerender the whole page just because the number of unread messages has changed? Here, Vue.js comes to help us. A programmer just needs to update the view-model and Vue.js will understand what has changed and will rerender only the Document Object Model (DOM) parts that actually changed. The following diagram schematizes this concept:

Figure 1.5: Vue.js updating a DOM node

The lesson is this: Spend time on designing explicit, meaningful models and let Vue.js take care of the performance and rendering logic.

The DOM is used to render a web page. See https://www.w3schools.com/js/js_htmldom.asp for more information.

Stores and private components model

Since views display data from stores, you may think that a view-model is just a portion of a store. Actually, each component can have a private model that can hold values that are needed just inside the component. There is no need to put every value in a store. Stores should contain only data relevant to the application.

For example, say you want to select some photos from a list and share them. The view-model of the photo list component will contain the list of selected photos, and when a user taps on the Share button, the view-controller just needs to dispatch an action called share-photos with the selected photo list as data in the action object. There is no need to put the selected photo list inside a store.

Summarizing Flux architecture

The following is the Flux architecture summarized in a single image:

Figure 1.6: Flux data flow explained